• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Resources
  • About
  • Schedule a Call

March 27, 2015 by James Jardine Leave a Comment

Amazon XSS: Thoughts and Takeaways

It was recently identified, and Amazon was quick (2 days) to fix it, that one of their sites was vulnerable to cross-site scripting. Cross-site scripting is a vulnerability that allows an attacker to control the output in the user’s browser. A more detailed look into cross-site scripting can be found on the OWASP site.

Take-Aways


  • QA could have found this
  • Understand your input validation routines
  • Check to make sure the proper output encoding is in place in every location user supplied data is sent to the browser

Vulnerabilities like the one listed above are simple to detect. In fact, many can be detected by automated scanners. Unfortunately, we cannot rely on automated scanners to find every vulnerability. Automated scanning is a great first step in identifying flaws like cross-site scripting. It is just as important for developers and QA analysts to be looking for these types of bugs. When we break it down, a cross-site scripting flaw is just a bug. It may be classified under “security” but nonetheless it is a bug that effects the quality of the application.

We want to encourage developers and QA to start looking for these types of bugs to increase the quality of their applications. Quality is more than just if the app works as expected. If the application has a bug that allows an attacker the ability to send malicious code to another user of the application that is still a quality issue.

If you are a developer, take a moment to think about what output you send to the client and if you are properly encoding that data. It is not as simple as just encoding the less than character or greater than character. Context matters. Look for the delimiters and control characters that are relative to where the output is going to determine the best course of action. It is also a good idea to standardize the delimiters you use for things like HTML attributes. Don’t use double quotes in some places, single quotes in others and then nothing in the rest. Pick one (double or single quotes) and stick to it everywhere.

If you are a QA analyst, understand what input is accepted by the application and then where that output is then used again. The first step is testing what data you can send to the server. Has there been any input validation put in place? Input validation should be implemented in a way to limit the types and size of data in most of the fields. The next step is to verify that any special characters are being encoded when they are returned back down to the browser. These are simple steps that can be performed by anyone. You could also start scripting these tests to make it easier in the future.

It is our (dev,qa,ba,application owners) responsibility to create quality applications. Adding these types of checks do not add a lot of time to the cycle and the more you do it, the less you will start to see allowing you to increase the testing timelines. Bugs are everywhere so be careful and test often.

Filed Under: Take-Aways Tagged With: cross-site scripting, developer, developer awareness, qa, qa awareness, quality assurance, security, security awareness, security testing, security training, xss

Reader Interactions

Leave a Reply

You must be logged in to post a comment.

Primary Sidebar

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
Email: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved