You know basically what I mean by "Web Security"
You've seen how I use an open-source testing tool
You get the gist of how to fix the bug we found
I've given you some ideas on where to explore next
is about...
Designing (Defenders)
Implementing (Builders)
and Testing (Attackers)
for a better WWW
and I don't just mean HTTPS
I can't give you 100 securities ;)
Can you spot two things wrong?
Leads to information disclosure, impersonation, financial loss & more!
"please don't hack me"
Even with the best defenses, humans can mess it all up
"Swiss cheese model of accident causation" by Davidmack - Own work. CC-BY-SA 3.0 via Wikimedia Commons
Security is hard, let's go hacking!
(In Canada, it's legal to own lock-picks, but illegal to possess "with the intention of committing a crime")
You should not attack any applications other than your own, and only do that with permission from the appropriate authorities (e.g. your company, your school)
if you take something from this talk and do something irresponsible, I won't be held liable.
App, Tool, and Objective
Gruere Codelab
google-gruyere.appspot.comOWASP ZAP
the Zed Attack ProxyFind a Cross-Site Scripting (XSS) vulnerability
XSS = Cross-Site Scripting
(english-idiom: X = cross)
One of the easiest errors to make when building a web site
Roughly, XSS is when you can run JavaScript on someone else's page
(For those reading slides after the talk, be sure to set the Scope to http://localhost:8008
and then enter Protected mode)
(Live coding goes here... or explaining a pre-prepared patch)
(Essentially: add apostrophe to filter in gtl.py, add :text in error.gtl)
XSS is caused by "breaking out" of one textual context into another
Parsers for a web page switch modes on certain control characters
Web languages provide syntax to "escape" those control characters
So, we escaped the problematic control characters!
Well known: "
, <
, >
, and &
Often overlooked: =
, '
(apostrophe), !
, /
, and `
(backtick)
Character | Encoding |
---|---|
" | " |
< | < |
> | > |
& | & |
' | ' |
generally: | HHHH; |
Briefly stated, theory is: escape control characters
This is a "block-list" approach
An "allow-list" approach can be more comprehensive
Start with "everthing's fine"
incrementally subtract; "this is not OK"
Benefits: easier to define
Problems: maintenance cost & missing important items
Start with "trust nothing"
incrementally add; "this is verified OK"
Benefits: resilient to yet-unknown threats
Problems: sometimes over-matches & breaks functionality
Be suspicious of block-list approaches
With a good team*, allow-list has less maintainance costs
* one that can consistently catch defects before they reach customers
Alpha-numeric is usually safe
Escape everything else using HHHH;
syntax
Use a template language with automatic escaping
Use a template language with contextual escaping
Use Content-Security-Policy (a topic worth another talk)
For more challenges, try the Gruyere Codelab on your own!
A free open-source self-contained training environment for Web Application Security penetration testing. Tools + Targets = Dojohttps://www.mavensecurity.com/web_security_dojo/
highlights:
Relative to the web, a nascent field!
Development strategies often focus on velocity
Need to stress: importance of threat modeling and secure coding practices
To generalize:
Attacker - paid to break into things
Defender - paid to make things less break-in-able
Builder - paid to ship a product, apply defenses