Embed Size (px)
Citation preview
XSS and How to EscapeTyler Peterson@managerJS
Bottom Line Up-Front (BLUF)• Anything from the user is
definitely unsafe.• Don’t render unsafe data
into script tags.• Do render html-escaped
data into html tags (including meta-tags).
Strange Bedfellows• XSS is a common attack vector
• Escaping is a commonly used countermeasure
• Can be effective but not a perfect fit
Escaping is All About Magic• Every interesting computing
context is a mix of data and magic.• The magic is triggered by special
data sequences.• It’s just like a wizard that can carry
out a normal conversation with no magic, then invoke magic using key-words.
Escaping (itself)• Escaping prepares data to enter a context with
different magic rules.
Escaping Algorithm: Deathstar to HogwartsReplace all protocol droids with house elves.
Magic Mismatch• When you don’t properly prepare data for the new
context you end up triggering magic on accident.
(Or On Purpose…)• Nefarious folks capitalize on our escaping mistakes
and abuse magic we fail to protect.
But Back to Escaping and Magic
Real Magic• RegExp: punctuation is magic, others are not
(mostly)
• HTML: <, >, and & are magic
• URL: /, &, ?, and # are magic
• SQL: ' and ` are magic
Really Real Magic• RegExp: different things are magic inside a character
class. E.g. - as in [-a-z]• HTML: Different things are magic inside a tag
definition. e.g. =, ", '. • URL: Different things are magic in host, path, query,
and fragment. E.G. the first ? begins the query, but they aren’t special in the fragment.
• SQL: Different things are magic inside a string: '' is an escaped quote.
Even Simple Languages are Hard• RegExp, HTML, URL, and SQL have magic that can
be difficult to reason about.
• Programming languages, like JavaScript, are even more complicated.–More contexts with different nuances–More magic and less data
Enter Cross Site Scripting (XSS)others making your page misbehave
Simple Data Rendering Example// template.ejsvar lang = "<%- locale %>";
• NOTE: I’m using EJS in these examples but the problems I illustrate are fundamental.
Simple XSS Attack• Attacker sendslocale = 'en"; doEvil(); "throw away string literal?'
• You rendervar lang = "en"; doEvil(); "throw away string literal";
Simple Escaping Countermeasure// template.ejsvar lang = "<%= locale %>";
You changed this to EJS’s back fat arrow. This does HTML escaping of the string before rendering it.
Attack Foiled!• This XSS vulnerability is closed.• The doEvil() function or code is NOT invoked.
How Did it Work?$ node> var ejs = require('ejs')undefined> var locale = 'en"; doEvil(); "throw away string literal'undefined> ejs.render('var lang = "<%- locale %>";')'var lang = "en"; doEvil(); "throw away string literal”;'> ejs.render('var lang = "<%= locale %>";')'var lang = "en"; doEvil(); "throw away string literal";'
1
2
How Good is the Fix?• No hands necessary, but please reflect:
– Have you ever done this?
– How certain are you that this is a high-quality fix?
Sidebar Example• You are hosting a 1 day, 2 event, classic video
game tournament.– Contra– Classic Doom
• No cheat codes allowed– Cheat codes are like magic– You can escape the codes to render them inert
Escape the Konami Code• What are you going to look for?
↑↑↓↓←→←→BA • You foil this cheat by inserting two “start”
commands right before the A.
Escape the Doom Clipping Code• What are you going to look for?– idspispopd
• You foil this by inserting any letter (but d) before the final d.
Flint’s Dad Mixes It Up• Your less adept colleague mixes up the cheat
detectors.• They work great but can’t stop the cheating.
Same Thing Happens With Escaping• Sometimes we escape till it works, but it’s really
not right.
Escaping Has Sharp Edges• Most escape algorithms treat most data the same,
because most data is non-magic most of the time.• The characters they treat differently—the edge
cases—are the most important parts to consider.• Take away: – It’s not enough to casually test an application of
escaping. – You need to thoroughly understand the old context, the
new context, and the joining algorithm.
Back to XSS: <%= Worked, but…• What if you had a number instead of a string?
> var onServer = '6; doEvil();'undefined> ejs.render('var count = <%= onServer %>')'var count = 6; doEvil();'
Missed Some Magic• The fix worked at first because " is magical in
JavaScript and HTML
• The fix failed because ; is only magical in JavaScript
Good Enough?• So, you’re kinda safe as long as you are using
strings OR at least match the untrusted string with a RegEx like /[^;'"]*/ and use the matched text instead of the full text.
My Tools Have Betrayed Me?!• Why is EJS so broken? Why doesn’t escaping help
me escape?
• It isn’t broken.
• Escaping isn’t a security measure. It only ferry’s data between magical worlds.
Escaping Must Match ContextFor escaping to be reliable you
have to match the new data context with the escaping
algorithm.
• The problem is that <%= (back fat arrow) is an HTML escape and you are rendering text into a JavaScript execution context.
The (Nonexistent) JavaScript Escape• So just switch to using JavaScript escape. Well,
there isn’t a standard JavaScript escape function so you can’t.
• What’s more, JavaScript has so many contexts that you shouldn’t write one.
What’s the Right Way™?• Render into HTML with an HTML escape
// template.ejs<meta name="lang" content="<%= lang %>">
• HTML escape replaces ', ", and >. An attacker can’t end the attribute.
The Right Way™ to Read:var metas = document.getElementsByTagName('meta');var i, l = metas.length, lang; for (i=0; i < l; ++i) { if (metas[i].getAttribute('name') == 'lang') { lang = metas[i].getAttribute('content'); }}
The Right Way™ is Kinda Yucky
• No wonder we take short-cuts.• Really is a good way to match escaping algorithms.• Read is awkward from scratch.
I Lied About JavaScript• The standard, safe way to encode data in
JavaScript is JSON.stringify().• JSON is a form of escaping so you must be careful
not to double escape.• Forces all data into a string context.
• npm/js-string-escape is similar and popular
JSON Example
> ejs.render('var count = <%- JSON.stringify(number) %>')'var count = "6; doEvil()"'
• JSON does the escaping so EJS doesn’t have to (in fact MUST NOT).
• Notice that JSON added quotes.
1
Show of Hands• Who likes the Right Way™?
• Who’s going to use the JSON Way?
OK, I Lied About JSON Being Safe• You’re not rendering into a JavaScript context.
• You’re rendering into a JavaScript context through an HTML context.
• Both magics can apply!
Here’s Your Template<!DOCTYPE html><html> <head><title>JSON Demo</title></head> <body> <script type="text/javascript"> var locale = <%- JSON.stringify(locale) %>; </script> <h1>Was it Safe?</h1></body></html>
These Attacks Work• '</script><h1>embarrassing content</h1>'• '</script><script>doEvil();</script><script>'
Rendering into a Script Tag is Doomed• Adding <%= makes the happy path fail• < and " are magical to HTML– so you have to escape them.– But the browser doesn’t replace the entity reference so
JavaScript sees an & and chokes.• Even if you found a way to do it–Would you remember it?–Would your team-mates understand and perpetuate it?
You Can’t Mix the Magics
Rules For Us Mere Mortals• The more you have to reason about the security of
a fix the less secure it is.• Every step in logic is an opportunity for error and
exploit.• In general, straightforward and yucky is more
secure than well reasoned and slick.• You can be slick, but you’re taking on risk.
Take Away: XSS Abuses Magic• A cross-site scripting attack is normally magic
masquerading as data.
Related: De-taint• Block the bad data at the front door.• No general solution.• Ideally unnecessary.• Escaping errors abound, so still a good idea to use.
Example: De-taint localevar pat = /[a-zA-Z_]{2,5}/pat.exec('en_US"; evil()')[0] // "en_US"
• Effectively limits evil.• Can accidentally be too restrictive, so be liberal.• Evil looking inputs are sometimes valid, so this
can’t be your only solution.
Final Recommendation• HTML escape data into meta tags and retrieve
them from JavaScript.• Pick a safe way and stick to it. No shortcuts.
Final Questions?
