XSS （Cross-site scripting）
XSS, cross-site scripting attack.
When accepting uncertain input content (e.g. third-party site messages, URL parameters, user-created text annotations, etc.), it is essential to verify the data before use and properly encode the data during presentation. Otherwise, malicious users may attack the website, and the lesser may only transfer irregular data, which may seriously attack the server and disrupt the normal operation of the website, e.g. injecting SQL scripts to clear all data on the server, etc.
Generally, when writing filters to verify user input, the filters should be based on white list (known security structure) configuration, allowing the white list to pass and not allowing other inputs; However, writing based on blacklist (known unsafe structure) configuration, that is, allowing all inputs except blacklist, is unsafe because there are many unknown unsafe things.
Usually we return to different pages of the user according to the specified parameters in the URL and provide the user with the following navigation:
<ul> <li><a href="blog.jhss.com?id=Home">Home</a> <li><a href="blog.jhss.com??id=About">About Site</a> <li><a href="blog.jhss.com??id=Account">My Account</a> </ul>
As above, if the above URL is directly displayed to the user without encoding, a malicious attacker can truncate the URL and insert one
If other users visit this URL page, they will execute any script in the injected script tag. Malicious people can specify malicious codes and steal user information.
There are also many ways to cheat the site to execute the injected code, the following are the aspects we should consider:
- When using seemingly harmless elements at that time, the attributes that they can use should be limited. For example,
<img>Element, if allowed
onloadProperty, the attacker can use the
onloadProperty to add a callback function to execute any specified code.
- When insertion is allowed
<base>Element, it means that the current page has all
<script>The relative addresses pointed to by the element will be
<base>The specified value is blocked, and all form submissions in the page will be redirected to the malicious site.
CSRF(Cross-site request forgery csrf
CSRF(Cross-site request forgery Cross-Site Request Forgery, also known as “One Click Attack” or Session Riding, is usually abbreviated asCSRFOr ..XSRF, is a malicious use of the website. Although it sounds like a cross-site script (XSS), but it is very different from XSS and the attack method is almost different. XSS leverages trusted users within the site whileCSRFThe trusted website is utilized by disguising requests from trusted users. AndXSSCompared with the attack,CSRFAttacks are often not popular (and therefore the resources to prevent them are quite scarce) and difficult to prevent, so they are considered to be more thanXSSMore dangerous.
Analysis of Causes and Solutions
If the site allows users to submit forms, such as applying for password modification and shopping settlement, it must be determined that the request was initiated by the user on his own initiative, and no other site tricked the user into making the request, because
HTMLForms in are allowed to be submitted across domains.
In order to prevent such attacks, the site can mainly carry out from two aspects:
- Fill in specific hidden tokens related to the user (
- Check each user request
OriginHead, i.e. request source
Providing a user interface for users to operate and supporting user interaction pages, sometimes malicious people will trick users to activate certain actions, then hijack clicked links, guide them to malicious websites, and carry out certain dangerous interactions, which is also what we need to pay attention to.
To avoid these situations, for some that do not need to be shown in
frameSites within the window are only allowed to be absent
frameWindow to display the user interface, such as through testing
windowObject and its
Original link:HTML application security