cross site scripting attack tutorial with examples
XSS (Cross Site Scripting) 공격,이를 방지하는 방법 및 XSS 테스트에 대한 전체 가이드.
XSS (Cross Site Scripting)는 모든 고급 테스터가 알고있는 가장 인기 있고 취약한 공격 중 하나입니다. 웹 애플리케이션에 대한 가장 위험한 공격 중 하나로 간주되며 해로운 결과를 초래할 수도 있습니다.
XSS는 종종이 공격 중에 클라이언트 측 언어가 주로 사용되기 때문에 유사한 클라이언트 측 공격과 비교됩니다. 그러나 XSS 공격은 덜 취약한 기술을 손상시킬 수 있기 때문에 더 위험한 것으로 간주됩니다.
이 XSS 공격 자습서에서는 이해하기 쉽도록 간단한 용어로 완벽한 예를 통해 유형, 도구 및 예방 조치에 대한 전체 개요를 제공합니다.
학습 내용 :
- XSS 공격 소개
- XSS는 어떻게 수행되고 있습니까?
- 교차 사이트 스크립팅 공격 유형
- XSS에 대해 테스트하는 방법?
- XSS 테스트 도구
- 다른 공격과의 비교
- XSS를 방지하는 방법
- 기술에 따른 예방
- XSS 치트 시트
- 결론
- 추천 도서
XSS 공격 소개
Cross Site Scripting 공격은 악성 코드 삽입으로 피해자의 브라우저에서 실행됩니다. 악성 스크립트는 웹 서버에 저장되어 사용자가 적절한 기능을 호출 할 때마다 실행될 수 있습니다. 웹 서버에 저장된 스크립트없이 다른 방법으로도 수행 할 수 있습니다.
이 공격의 주요 목적은 쿠키, 세션 토큰 및 기타 정보와 같은 다른 사용자의 신원 데이터를 훔치는 것입니다. 대부분의 경우이 공격은 다른 사람의 쿠키를 훔치는 데 사용됩니다. 아시다시피 쿠키는 자동 로그인을 도와줍니다. 따라서 도난당한 쿠키를 사용하면 다른 ID로 로그인 할 수 있습니다. 이것이 바로이 공격이 가장 위험한 공격 중 하나로 간주되는 이유 중 하나입니다.
XSS 공격이 클라이언트 측에서 수행되고 있습니다. 다른 클라이언트 측 프로그래밍 언어로 수행 할 수 있습니다. 그러나 대부분의 경우이 공격은 Javascript 및 HTML로 수행됩니다.
추천 읽기=> HTML 주입 튜토리얼
XSS는 어떻게 수행되고 있습니까?
교차 사이트 스크립팅 공격은 악성 코드 또는 스크립트를 보내고 주입하는 것을 의미합니다. 악성 코드는 일반적으로 Javascript, HTML, VBScript , Flash 등. 그러나이 공격을 수행하기 위해 주로 Javascript와 HTML이 사용됩니다.
이 공격은 다른 방식으로 수행 될 수 있습니다. XSS 공격의 유형에 따라 악성 스크립트가 피해자의 브라우저에 반영되거나 데이터베이스에 저장되어 사용자가 적절한 기능을 호출 할 때마다 실행될 수 있습니다.
이 공격의 주된 이유는 악의적 인 입력이 출력에 들어갈 수있는 부적절한 사용자의 입력 유효성 검사입니다. 악의적 인 사용자가 스크립트를 입력하면 웹 사이트 코드에 삽입됩니다. 그러면 브라우저는 실행 된 코드가 악성인지 아닌지 알 수 없습니다.
따라서 피해자의 브라우저에서 악성 스크립트가 실행되고 있거나 사용자에게 가짜 형태가 표시되고 있습니다. XSS 공격이 발생할 수있는 몇 가지 형태가 있습니다.
크로스 사이트 스크립팅의 주요 형태는 다음과 같습니다.
- 교차 사이트 스크립팅은 클라이언트 측에서 실행되는 악성 스크립트에서 발생할 수 있습니다.
- 사용자에게 표시되는 가짜 페이지 또는 양식 (피해자가 자격 증명을 입력하거나 악성 링크를 클릭하는 위치).
- 광고가 표시된 웹 사이트에서.
- 피해자에게 악성 이메일이 전송되었습니다.
이 공격은 악의적 인 사용자가 웹 사이트에서 취약한 부분을 찾아 적절한 악성 입력으로 보낼 때 발생합니다. 악성 스크립트가 코드에 삽입 된 후 최종 사용자에게 출력으로 전송됩니다.
간단한 예를 분석해 보겠습니다. 검색 필드가있는 웹 사이트가 있다고 가정 해 보겠습니다.
검색 필드가 취약한 경우 사용자가 스크립트를 입력하면 실행됩니다.
사용자가 아래와 같이 매우 간단한 스크립트를 입력한다고 생각해보십시오.
alert(‘XSS’)
그런 다음 '검색' 버튼을 누르면 입력 한 스크립트가 실행됩니다.
우리가 볼 수 있듯이 예 ,검색 필드에 입력 된 스크립트가 실행됩니다. 이것은 XSS 공격의 취약성을 보여줍니다. 그러나 더 유해한 스크립트도 입력 할 수 있습니다.
많은 테스터가 교차 사이트 스크립팅 공격을 자바 스크립트 주입 , 이는 클라이언트 측에서도 수행되고 있습니다. 둘 다 공격 악성 스크립트가 주입되고 있습니다. 그러나 XSS 공격의 경우 스크립트를 실행하는 데 태그가 필요하지 않습니다.
예를 들어 :
;
또한 다른 이벤트에서 실행되는 스크립트 일 수도 있습니다.
예를 들면 :마우스를 가리키면.
다른 예를 분석해 보겠습니다.웹 사이트에 최신 서평이 표시되는 페이지가 있습니다.
이 페이지의 코드는 다음과 같습니다.
print '' print '. If this vulnerability is present in the web application, an indicated text will be inserted intags. Trying to pass some code through HTTP request as this is also a method to check if this attack is possible.
Generally, while testing for possible XSS attack, input validation should be checked and the tester should be conscious while checking the website’s output. Also if a code review is being performed, it is important to find how input can get into the output.
XSS Testing Tools
As Cross Site Scripting attack is one of the most popular risky attacks, there are a plenty of tools to test it automatically. We can find various scanners to check for possible XSS attack vulnerabilities – like, Nesus and Nikto. Both of which are considered as quite reliable.
From my software testing career, I would like to mention SOAP UI tool. SOAP UI can be considered as a quite strong tool for checking against the possible XSS attacks. It contains ready templates for checking against this attack. It really simplifies the testing process.
However, in order to test for this vulnerability with SOAP UI tool, API level testing should already be automated with that tool. Another solution to test against XSS can be browser plugins. However, plugins are considered as quite a weak tool to check against this type of attack.
Even while testing automatically, the tester should have good knowledge of this attack type and should be able to analyze the results appropriately.
Good knowledge is also helpful while selecting the testing tool. Also, it is important to know, that while performing scanning for security vulnerabilities with an automatic tool, testing manually is also a good practice and this way the tester will be able to see the results and analyze them.
Recommended Tool:
#1) Kiuwan

Find and fix vulnerabilities in your code at every stage of the SDLC.
Kiuwan is compliant with the most stringent security standards including OWASP, CWE, SANS 25, HIPPA, and more. Integrate Kiuwan in your IDE for instant feedback during development.
Kiuwan supports all major programming languages and integrates with leading DevOps tools.
=> Scan your code for free
Comparison with Other Attacks
XSS is considered to be one of the riskiest attacks, as its main purpose is to steal the website’s or system’s user identities. Also, XSS attack can be performed with different client-side languages like Javascript, HTML, VBScript, Flash, etc. And this makes it more harmful and widespread than the other possible attacks.
Testing for XSS attack is quite similar to testing for the other possible client-side attacks. However, it is important to remember what additional cases should be checked while testing for XSS.
Another thing, that makes this attack riskier is the possibility to be stored in the web service – this way it can affect many users for a longer period of time. XSS sometimes can be performed to even less vulnerable systems and its vulnerabilities are sometimes difficult to be found.
Also, while comparing with the other attacks, XSS has many ways to be performed and affect the website as well.
Ways to Prevent XSS
Though this type of attack is considered to be one of the most dangerous and risky one, still a preventing plan should be prepared. Because of the popularity of this attack, there are quite many ways to prevent it.
Commonly used main prevention methods include:
- Data validation
- Filtering
- Escaping
The first step in the prevention of this attack is Input validation . Everything, that is entered by the user should be precisely validated, because the user’s input may find its way to the output. Data validation can be named as the basis for ensuring the system’s security. I would remind, that the idea of validation is not to allow inappropriate input.
Therefore it just helps to reduce the risks, but may not be enough to prevent the possible XSS vulnerability.
Another good prevention method is user’s input filtering. The idea of the filtering is to search for risky keywords in the user’s input and remove them or replace them by empty strings.
Those keywords may be:
- tags
- Javascript commands
- HTML markup
Input filtering is quite easy to practice. It can be performed in different ways too.
Like:
- By developers who have written server-side code.
- Appropriate programming language’s library is being used.
In this case, some developers write their own code to search for appropriate keywords and remove them. However, the easier way would be to select appropriate programming languages library to filter the user’s input. I would like to comment, that using libraries is a more reliable way, as those libraries were used and tested by many developers.
Another possible prevention method is characters escaping . In this practice, appropriate characters are being changed by special codes. For Example, Meanwhile, good testing should not be forgotten as well. It should be invested in good software testers knowledge and reliable software testing tools. This way good software quality will be better assured.
Prevention According to Technologies
As already discussed, filtering and characters escaping are the main prevention methods. However, it can be performed differently in different programming languages. Some programming languages have appropriate filtering libraries and some do not.
It should be mentioned, that filtering can be performed quite easily in Java and PHP programming languages, as they have appropriate libraries for it.
Java technology is quite widely used, therefore there are many solutions to it. If you are using Spring technology and if you would like to escape HTML for the whole application, then you have to write the appropriate code in the project’s web.xml file.
defaultHtmlEscape true
이 코드는 전체 애플리케이션에 대해 HTML 이스케이프를 전환합니다.
해당 페이지의 양식에 대한 HTML 이스케이프를 전환하려면 코드를 다음과 같이 작성해야합니다.
.jar 파일 형식의 준비된 XSS 필터가 많이 있습니다. .jar 파일을 프로젝트에 추가해야하며 그 후에 만 해당 라이브러리를 사용할 수 있습니다. 이러한 XSS 필터 중 하나는 서블릿 필터 인 xssflt.jar입니다. 이 .jar 파일은 인터넷에서 쉽게 다운로드하여 프로젝트에 추가 할 수 있습니다.
이 필터는 애플리케이션으로 전송되는 모든 요청을 확인하고 잠재적 주입에서이를 정리합니다.
YouTube 비디오를 mp3로 다운로드하는 웹 사이트
external.jar 파일이 프로젝트에 추가되면 web.xml 파일에도 설명되어야합니다.
XSSFilter com.cj.xss.XSSFilter
또 다른 가능한 솔루션은 ESAPI 라이브러리입니다. ESAPI 라이브러리는 많은 프로그래밍 언어와 호환됩니다. Java 및 PHP 프로그래밍 언어 용 ESAPI 라이브러리를 찾을 수 있습니다. 애플리케이션의 보안을 제어하는 데 도움이되는 오픈 소스 및 무료 라이브러리입니다.
XSS 치트 시트
XSS 치트 시트는 사이트 간 스크립팅 방지에 매우 유용 할 수 있습니다. XSS 공격을 방지하는 방법에 대한 개발자를위한 지침입니다. 규칙은 매우 도움이되며 개발 중에 잊어서는 안됩니다. XSS 치트 시트는 OWASP (The Open Web Application Security Project)와 같은 인터넷 커뮤니티에서 찾을 수 있습니다.
다양한 유형의 치트 시트 :
- XSS 예방 치트 시트
- DOM XSS 치트 시트
- XSS 필터 회피 치트 시트
주요 지침은 XSS 공격 방지를위한 공통 규칙을 제공하는 XSS 방지 치트 시트입니다. DOM XSS 치트 시트 및 XSS 필터 회피 치트 시트 규칙을 따를 경우 여전히 XSS 예방 치트 시트를 따라야합니다.
언급했듯이 XSS 예방 치트 시트는 OWASP 커뮤니티에서 찾을 수 있습니다. 이 치트 시트는 가능한 XSS 공격의 위험을 줄이는 데 도움이되는 규칙 목록을 제공합니다. 코딩 규칙뿐만 아니라 예방 차원의 보안 취약점이기도합니다.
다음과 같은 몇 가지 규칙이 있습니다.
- 신뢰할 수없는 데이터는 삽입하면 안됩니다.
- 신뢰할 수없는 데이터를 삽입하기 전에 HTML을 이스케이프해야합니다.
- 신뢰할 수없는 데이터 등을 삽입하기 전에 속성을 이스케이프해야합니다.
따라서 치트 시트는 이러한 유형의 공격을 방지하는 데 매우 유용 할 수 있습니다.
결론
테스트하는 동안 가능한 XSS 공격을 유발하는 위험을 평가하는 것이 좋습니다. XSS 공격은 안전 해 보이는 웹 애플리케이션에도 영향을 미칠 수 있습니다.
가장 해롭고 위험한 공격 중 하나로 간주됩니다. 따라서 우리는 이러한 유형의 테스트를 잊지 말아야합니다. XSS에 대한 테스트를 수행하는 동안이 공격에 대해 잘 알고있는 것이 중요합니다. 그리고 이것은 테스트 결과를 올바르게 분석하고 적절한 테스트 도구를 선택하는 기초입니다.
크로스 사이트 스크립팅 XSS 공격을 처리 한 테스터입니까? 독자들에게도 도움이 될 XSS 공격에 대한 흥미로운 사실이 있습니까? 아래 댓글 섹션에서 우리와 함께 경험을 공유하십시오 !!
추천 도서