In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/01 Report--
This article mainly shows you "how to prevent XSS attacks", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "how to prevent XSS attacks" this article.
Cross-site scripting is the second most common problem in the top 10 of the Application Security Open Source Foundation (OWASP)-it exists in about 2% of all applications. While automation tools can detect some of these problems, there are also automation tools designed to detect and exploit these vulnerabilities.
What is cross-site scripting?
A XSS attack occurs when data enters a Web application through an untrusted source, such as an Web request, and is sent to the user without authentication.
XSS can cause scripts to be executed in the user's browser, resulting in session hijacking, website tampering, and redirecting the user to a malicious site.
In essence, an attacker enters malicious code into a part of user input that the server wants to be data (but actually code designed for execution).
If not handled properly, malicious code may break through the "data plane" and execute as normal code ("control plane").
We can divide most XSS attacks into two categories: stored and reflected. The third, which is less common, is called DOM-based XSS.
Any XSS attack occurs when data is entered through an untrusted source and sent to the user (in dynamic content) without checking for malicious content. Malicious content can be JavaScript, Flash, HTML, or any other code that the browser can execute.
Reflective XSS (impact: medium)
This is the most basic XSS type, where the application receives data and then includes it in the response to the user in an unsafe manner.
For example, if the attacker persuades the user to click this phishing link:
Http://legitwebsite.com/message= malicious code
If the legitimate site does not process the data but simply returns it to the user, the user's browser will execute malicious code.
Storage XSS (impact: severe)
A stored XSS occurs when the injection is permanently stored on the target server, such as forums or comments, messages in the database, and so on. In essence, this means that the vulnerability affects every visitor to the site / application.
For example, if the site allows users to post comments and then displays their comments, the user can enter the following:
Malicious code
If the site does not check user input properly, it may cause the script to execute for any other user who sees this message.
DOM-based XSS/ client XSS (impact: medium)
The biggest difference between reflective XSS and memory XSS and DOM-based is the injection location of the attack.
Reflecting and storing XSS is a server-side problem, while DOM-based is a client-side (browser) problem. DOM-based XSS occurs in DOM (document object Model), not as part of HTML.
Instead of inserting malicious code into the page, this attack allows you to load a legitimate page and then use user input to add HTML to the page to execute a malicious script. This takes advantage of the increasing number of HTML generated by the client.
For example, an attacker can cause a victim to click on a malicious link (such as http://www.legitimatewebsite.com/contact#malicious code) through social engineering. The site will receive a legitimate request for the page, but will not receive a malicious fragment (because the browser will not send anything after # characters to the site's server). The victim will see a legitimate website, but the victim's browser will also execute malicious scripts.
Because of the way this attack works, server-side protection does not stop it because malicious code is not sent to the server at all.
Instead, preventing such an attack requires ensuring that JavaScript does not interpret URI fragments in an insecure manner (uniform Resource Identifier-URI identifies resources at a specified location, such as URL).
Mitigation measures of XSS attack
Effective mitigation of XSS attacks requires a combination of the following measures, which, when used in combination, can provide strong XSS defense.
Avoid inserting user-provided / untrusted data anywhere other than the specified location
This is the first and most important rule. Encoding, escaping, validating, and filtering input is extremely difficult and complex.
It is much easier to limit where someone can enter untrusted data. The safest assumption is that all untrusted data is malicious.
Validate / filter input
Ideally, all inputs should be validated against a list of acceptable values.
Coding output
Any data entered by the user should be encoded to prevent it from being read as active. This may require CSS, JavaScript, URL, and / or HTML encoding.
It is particularly important to ensure that the output is encoded at any exposed point, because the same data can be stored and displayed in multiple locations.
Choose the framework carefully
Use a framework that provides automatic escape capabilities, such as Go templates, or a framework that has native defenses against XSS, such as request authentication for .NET.
Set the HttpOnly flag
XSS attacks usually use JavaScript to steal the session cookie (whereas ordinary Web applications rarely need to use JavaScript to access the session cookie). Therefore, setting the HttpOnly flag protects the session cookie from attackers without restricting normal behavior. Most browsers support setting this flag.
Use response headers
Like the HttpOnly flag, any HTTP response that should not contain HTML or JavaScript can use the "Content-Type" and "X-Content-Type-Options" headers to ensure that the browser interprets the response only as expected.
Educate developers on safety
Education for developers, such as the "security champion" program that matches application security team members with developers, is important. They can help developers understand security vulnerabilities such as XSS and how to prevent them.
Develop content security policy
Content Security Policy (CSP) can help you detect and mitigate XSS and other data injection attacks.
They set up a license list for sources of trusted content and can only be applied to sensitive pages (such as payment pages) or, ideally, to the entire site. If the content is loaded on a page that should never be loaded, they can even provide notifications.
They are fairly easy to deploy-just add Content-Security-Policy HTTP headers to the web page and any appropriate directives.
The CSP fiddler extension can help you generate a benchmark CSP. The tool builds the policy around the reports submitted by the browser and creates a changeable baseline policy.
In addition, you can use Report URI run by Troy Hunt and Scott Helme to get alerts about CSP violations to more proactively monitor your site.
Typically, a policy consists of a series of instructions that describe the policy of a resource or area. One of these instructions, the subresource integrity check, is used to ensure that the browser verifies that third-party content (from sources such as CDN) is delivered without being manipulated.
In essence, the encrypted hash provided must match the loaded file. If the hacker modifies the content of a third party, the site will not load malicious content.
The problem is that if the content provider updates the file or makes legal changes, the content will not be loaded (because the hash value has changed).
The main way to solve this problem is to make use of versioned JavaScript resources, such as chatbot_0.1.23.js, rather than chatbot.js. This is a general best practice and ensures service continuity when JS files change.
Although browsers don't generally support this feature, for browsers that lack it, using it won't damage the site (it just won't take advantage of the technology).
The above is all the contents of the article "how to prevent XSS attacks". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.