Cross-Site Scripting Vulnerability
XSS is a place of vulnerability in the Web front-end, so the object of the harm is mainly front-end user.
XSS vulnerabilities can be used for phishing attacks, the front js mining, get the user cookie. Even the browser itself can be combined with the vulnerability of the user host remote control.
XSS attacks Process
After the discovery of the existence of such a site XSS vulnerabilities will be how attackers exploit it
for example, now is a relatively well-known forum, an attacker can differ according to the type of XSS vulnerabilities, malicious JS code is inserted into this through this XSS vulnerability one page among the forum, then trick the user to access or wait for users to access, when the user accesses the page, will perform JS code with malicious script ,, the JS malicious script code in a user's browser will end run, for example, the malicious JS code is to get the user's cookie, secretly sent to the attacker's own interface built after he would get into the user's cookie, you can as a user after the attacker then got cookie landing forums, so that you can be tampering with information on the forum.
Common types of cross-site scripting vulnerability
Hazard: storage type> reflective> DOM type
Reflective
data exchange generally not exist inside the database, a one-time, WYSIWYG, generally appear in the query category page and so on.
Storage-type
data exchange will be the presence of the database, persistent storage, usually appears in the message boards, registration page.
DOM type
is not generated exchanging data with back-end server is a matter of DOM operations by the front-end code generated when output, also belong to the reflection-type disposable.
The reason XSS vulnerability formed
XSS vulnerability is the main reason for the formation of a program to control inputs and outputs are not stringent enough, leading to the "carefully constructed" script input, output to the front when the browser is treated as a valid code analysis execution resulting harm.
Cross-site scripting vulnerability testing process
1. Locate the entry point at the target site, such as query interface, message boards, etc.
2. Enter a group of "special character + unique identification character", click submit, to see the return of the source code, if there is a corresponding process do
3. locate by searching the unique characters, unique characters before and after the binding conditions syntax can be configured to confirm whether the execution js (closed configuration)
4. Submit configuration script code (and all the bypass position), may be performed to see if successful, then there is performed if successful XSS loophole
TIPS：
1. General query interface is easy to appear reflective XSS, storage-type XSS message boards prone to
2. Because of the background there may be filtering measures, script structure may be filtered out, and could not be effective, or limit the execution environment (browser)
3 through different variations script, try to bypass filtering mechanisms background
Reflective XSS loopholes get & post
XSS vulnerability GET way easier to be used, the general approach is to use with camouflage sent to the target URL after cross-site scripting, and because the POST method is a form submission, you can not use direct URL ways to attack.
In simple terms, GET and POST typical differences:
GET submit data in the manner url
POST request to submit a form inside the body
