Cross-site scripting (XSS) is an attacking technique which forces the Web application to forward the executable attack code to the user, which then loads in the user's Web browser and executes. Attack code is often written by using the JavaScript scripting language, but also other programming languages which are supported by the user's Web browser: VBScript, ActiveX, Java and Flash. When the attacker manages to encourage the user's Web browser to carry out the execution of the attack code, this code will run within the security zone of the Web application. By using this privilege, the attack code will be able to read, modify or forward the confidential data given to the Web browser. Thus, this attacking method can be used for stealing accounts (cookies), directing the Web browser to other sites and forwarding malicious content by Web application. Thus, cross-site scripting attacks also jeopardize the confidential relationship between the user and the Web application.
In general, there are two types of cross-site scripting attacks: non-persistent and persistent. Non-persistent attacks lead user to visit specifically created links which are associated with harmful code. When the user visits this link, the code which is stored inside the URL will be done within the user's Web browser. More cautious users can spot danger if they notice the script inside the link content, so the attackers often convert the code by using Hex encoding to hide the trace of the script and to trick users. On the other hand, persistent attacks occur when certain harmful code is stored within the Web application for some time. These applications are usually portals, Web mail or Web chat applications. It is not necessary that the user clicks on some link, but it is enough to just view the content of the Web page which contains harmful code. In general, to check each Web application for XSS vulnerability, it is necessary to insert a simple Javascript alert message alert(XSS) in the part of the Web applications which can be seen again (typically, the URL or message on some forum). After setting the message, it is necessary to look whether the Web browser will respond with the pop-up message box. If the window appears, that is the sign that the script has been executed and that there is a XSS vulnerability. This is one of the common attack methods, so it is advisable to make additional security measures to av o i dsuch attacks:
- Disabling scripts when they are not required. This security measure prevents the code execution within the user's Web browser by using a script (in URL), but there is still a danger from specifically created attack HTML d o c u m e n ts, which are usually forwarded to the user via e-mail.
- Filtering user requests. The Web application always checks the user requests and filters special m e t a-characters defined by HTML specification in order to check whether the user query contains the script. If this query contains a script, the Web application prevents the display of malicious HTML d o c u m e n t inside the user's Web browser.
- Coding of pages. Cross-site scripting attacks can be av o i ded if the Web server correctly encodes the generated pages to prevent unintentional execution of scripts.
In general, there are two types of cross-site scripting attacks: non-persistent and persistent. Non-persistent attacks lead user to visit specifically created links which are associated with harmful code. When the user visits this link, the code which is stored inside the URL will be done within the user's Web browser. More cautious users can spot danger if they notice the script inside the link content, so the attackers often convert the code by using Hex encoding to hide the trace of the script and to trick users. On the other hand, persistent attacks occur when certain harmful code is stored within the Web application for some time. These applications are usually portals, Web mail or Web chat applications. It is not necessary that the user clicks on some link, but it is enough to just view the content of the Web page which contains harmful code. In general, to check each Web application for XSS vulnerability, it is necessary to insert a simple Javascript alert message alert(XSS) in the part of the Web applications which can be seen again (typically, the URL or message on some forum). After setting the message, it is necessary to look whether the Web browser will respond with the pop-up message box. If the window appears, that is the sign that the script has been executed and that there is a XSS vulnerability. This is one of the common attack methods, so it is advisable to make additional security measures to av o i dsuch attacks:
- Disabling scripts when they are not required. This security measure prevents the code execution within the user's Web browser by using a script (in URL), but there is still a danger from specifically created attack HTML d o c u m e n ts, which are usually forwarded to the user via e-mail.
- Filtering user requests. The Web application always checks the user requests and filters special m e t a-characters defined by HTML specification in order to check whether the user query contains the script. If this query contains a script, the Web application prevents the display of malicious HTML d o c u m e n t inside the user's Web browser.
- Coding of pages. Cross-site scripting attacks can be av o i ded if the Web server correctly encodes the generated pages to prevent unintentional execution of scripts.
Son düzenleme:
