search

OWASP / CheatSheetSeries

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.
https://cheatsheetseries.owasp.org
Creative Commons Attribution Share Alike 4.0 International
28.12k stars 3.94k forks source link

Update: XSS Prevention Cheat Sheet to show common failed anti-patterns attempted as XSS defense #1092

Closed kwwall closed 9 hours ago

kwwall commented 1 year ago

What is missing or needs to be updated?

The current XSS Prevention Cheat Sheet is great at describing what developers should do to prevent XSS vulnerabilities and that definitely should be (and is) its primary focus. But despite that, there is a lot of bad advice elsewhere on the Internet (e.g., Stack Overflow is one such common source of misinformation out there) where developers ignore the advice in this XSS Prevention CS in search of a short cut so that they can avoid providing specific output encoding at or near the hundreds or more given XSS sinks that SAST or DAST or manual code reviews discover.

Instead of using the approaches recommended in the XSS Prevention CS, I often find developers trying to solve XSS vulnerabilities with a single, simple, stop-gap solution, such as only using CSP headers as a defense or only using HTTP interceptors to provide HTML sanitization or output encoding in a single specific context (usually HTML). While those approaches might be useful as a defense-in-depth layer (depending on the situation), the never actually fully remediate the XSS vulnerabilities.

If this were just a few cases it would be easy enough to deal with, but for every case where I find these misguided approaches during code review, or every time that @xeno6696 or I correct someone asking an ESAPI-related XSS question on Stack Overflow, I am confident that we are missing several others. However, both Matt and I have seen these approaches both in code and discussed as "solutions" frequently enough to realize that it is a common anti-pattern.

Therefore, I think it would be useful to have a small section in the XSS Prevention CS to call out how NOT to defend against XSS vulnerabilities.

How should this be resolved?

To partially address this problem, I have wrote up the detailed ESAPI wiki post, XSS Defense: No Silver Bullets that I now refer developers I find doing this (which are a lot) to that wiki page. However, as I mentioned in https://github.com/OWASP/CheatSheetSeries/issues/517#issuecomment-1435757162, I think this advice would be more effective if the essential parts of it can be distilled and included in the XSS Prevention Cheat Sheet where I think many more developers look first.

So, I am proposing to create a PR that will highlight the main points from the ESAPI wiki page in the XSS Prevention CS and then link to it for anyone wanting to see more details.

kwwall commented 1 year ago

I'm thinking of adding a new short section called something like "Common Ineffective Approaches to Avoid", but I'm not sure where it would best be placed. I was thinking toward the end, either before or after the "Other Controls" section.

My question is, would you rather see this proposed new section before or after the "Other Controls" section?

szh commented 1 year ago

IMHO after would be best

xeno6696 commented 1 year ago

I agree with after, though we should use the term "antipatterns" as that will make more devs snap to attention. "pitfalls" implies something small. Antipattern implies wrong from conception.

xeno6696 commented 1 year ago

I'll review this week.

xeno6696 commented 1 year ago

Been awhile since I read through it, "antipatterns" are used throughout. (For some reason I thought you implied a rewrite.)

Yeah, after. Show them how to do it right, and then after all that, we diatribe against doing it wrong.

kwwall commented 1 year ago

The XSS Prevention CS already shows how to "do it right" (although, it unfortunately no longer discusses when / where / why mixed output encoding may be required), but developers still commonly mess it up. I largely think because the bad advice outweighs the code advice by quite a bit. (That's especially true for PHP where I found most references to XSS defense just wrong.)

mackowski commented 8 months ago

@kwwall do you still want to work on this?

kwwall commented 8 months ago

Yes. Sorry. Totally forgot about it. I actually had it mostly done and then got distracted when my presentation was accepted for BSides Columbus and OWASP Global AppSec DC and I focused mostly on that. I'll see if I can this week.

-kevin

On Sun, Feb 18, 2024, 11:52 AM mackowski @.***> wrote:

@kwwall https://github.com/kwwall do you still want to work on this?

— Reply to this email directly, view it on GitHub https://github.com/OWASP/CheatSheetSeries/issues/1092#issuecomment-1951383655, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO6PG7NPTTYOAGTXYGYLRLYUIWWRAVCNFSM6AAAAAAVCDE422VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGM4DGNRVGU . You are receiving this because you were mentioned.Message ID: @.***>

mackowski commented 8 months ago

Awesome :)

kwwall commented 8 months ago

Just created a PR to review. See above.

I will close this issue once the PR is approved and merged. (Or someone else can.)