Why cross-site scripting still matters
2023-4-7 02:39:49 Author: www.synopsys.com(查看原文) 阅读量:34 收藏

Posted by on Thursday, April 6, 2023

With web application exploits the 3rd-most-common cybersecurity threat, overlooking the importance of XSS vulnerabilities puts you at risk.

cross-site scripting | Synopsys

As we move through 2023, many organizations are looking at their cybersecurity programs and considering how to allocate their application security testing resources. While allocating testing resources to OWASP Top 10 vulnerabilities like cross-site scripting (XSS) may not feel innovative, it’s one of the best ways to ensure an organization’s security.

According to Forrester’s “The State of Application Security: 2022” report, web application exploits remain the third-most-common cybersecurity threat. Of the 4,000+ tests Synopsys Application Security Testing services conducted for its annual “Software Vulnerability Snapshot” report, 95% uncovered some form of vulnerability in the target applications.

Web app attacks account for 70% of cyberattacks, and attacks starting in web apps increased from 32% in 2020 to 54% in 2021. While not all these attacks originate as XSS attacks, in an environment where new web attacks are happening every 39 seconds and more than 30,000 websites are attacked every day, taking care of the basics and addressing issues like XSS vulnerabilities is crucial to protecting the security of your business and your reputation.

So what are XSS vulnerabilities and how can effective application security testing help your organization detect and mitigate them?

Cross-site scripting

Cross-site scripting vulnerabilities are one of the most common online application security concerns, in part because they are easy to introduce but hard to discover and fix. This means there’s always the danger that they’ll get into production code.

XSS attacks work by inserting malicious code into trustworthy websites. When the webpage is loaded, the malicious code is executed in the user’s browser, allowing the attacker to steal sensitive information such as passwords and cookies, or perform other malicious actions. These attacks can be successfully conducted everywhere a web application incorporates user input without verifying or encoding it into the output it produces.

In some instances, an XSS attack causes the victim’s account to be totally compromised. Users can be duped into entering their credentials on a false form, which gives the attacker access to all the data.

The three kinds of XSS attacks

There are three main types of XSS attacks.

  • Stored XSS attacks: These occur when the injected script is kept on the target servers indefinitely, such as in a database, message board, visitor log, comment field, etc. When the victim makes a request for the stored data, the server returns the malicious script.
  • Reflected XSS attacks: These are sent to targets through a channel like an email message or website. When a user is tricked into clicking a malicious link, submitting a specially crafted form, or even just browsing a malicious site, the injected code travels to the vulnerable website, which reflects the attack back to the user’s browser. And because the code came from a “trusted” server, the browser runs it.
  • DOM-based XSS: This occurs when the attacker’s payload is stored on the server and reflected back to the victim by the back-end application. In feedback forms, an attacker can submit a malicious payload that will be executed when the back-end user or admin opens the form.

How to prevent XSS vulnerabilities

By following secure development best practices and integrating security throughout all phases of application development, you can safeguard your organizational security. This includes putting security measures in place early in the secure development life cycle (SLDC). For instance, threat modeling and architecture risk analysis should be undertaken during the software design phase and should take XSS vulnerabilities into account. Other methods of preventing XSS attacks include

  • Never rely on user feedback.
  • Put output encoding into practice.
  • Make sure user input is accurate.
  • Observe “defense-in-depth” practices.
  • Use OWASP’s XSS Prevention Cheat Sheet during web application development.
  • Perform penetration testing after remediation.

Output encoding is another crucial component of XSS vulnerability defense. Use output encoding libraries that are suitable for the frameworks and coding languages your business uses. And finally, make sure your engineers are trained in the best ways to prevent XSS.

How Synopsys can help

Because vulnerabilities like XSS are ubiquitous in a world where we’re all trying to manage software risk without impeding business velocity, security testing is now a standard part of developing software. Buyers have a large selection of vendors and tools to pick from, but in order for an application security approach to be effective, you need more than just individual tools. You need to align your people, processes, and technology to address security risks based on your organization’s unique policies and business objectives.

Synopsys can help your business develop a comprehensive application security testing program. Our tools and consulting resources can help you understand the risks your business faces, so you can develop a strategy complete with implementation plans and policies. We can help you determine if your security and development teams have the right skills to guarantee the reliability of the software your company uses and develops, and together, we can help you tool up those teams so they can secure software as fast as they develop it.

Synopsys is the only vendor that delivers not only a complete portfolio of industry-leading tools, but also the consulting, expert security testing, training, and global deployment and support services to ensure our customers are successful with their AppSec programs.

Learn about key AppSec program considerations


文章来源: https://www.synopsys.com/blogs/software-security/why-cross-site-scripting-still-matters/
如有侵权请联系:admin#unsafe.sh