xss the gloves are off andy prow managing director, aura software security ltd...
TRANSCRIPT
XSSThe Gloves are Off
Andy ProwManaging Director,
Aura Software Security [email protected]
.nz
Kirk JacksonSenior Developer
The Message
“XSS can fully compromise your site’s users’ machine – which might include
you”
“XSS is easy to protect against as long as take the right precautions”
Who are we?o Andy Prow – Managing Director of Aura
Software Security Ltdo Security Consultants - Penetration Testerso Performed web application pen-testing for
both NZ, Ausy and UK companies. o Govt, corporate and bankingo Wellington based.o BSc Hons in Comp Sci and Soft Eng – 14
years software dev experience.
Who are we?o Kirk Jackson – Developer & Security Officer,
Xero http://www.xero.como Microsoft MVP – ASP.NETo Organises the Wellington .NET user group –
25 user groups nationwide: http://www.dot.net.nz
o Blog: http://pageofwords.com
Are the Threats Real?• XSS attacks include:
oTwitter, FaceBook, PayPal, Google, MySpace, WordPress, etc...................
• XSS attacks have / can:o Inject rude images and abusive pop-upsoTargeted CSRFo“Own” their browser – example in a mo...oPerform port scans from their machineoDownload full malware to compromise their
machine
XSS 101
XSS ShellThe Victim...
XSS ShellThe Command and Control Console...
XSS Attack and Defence• The gloves are off...
XSS Attack and Defence• NOTE: slides 11 (this slide) to slide 49 are
taken from the Live demo, using a .Net 3.5 web-application. Each set of slides shows Andy’s XSS attacks and then Kirk updates to the code – rebuild – rerun and therefore
DEFEND the attack.• The real preso slides start again at 50.
XSS Attack and Defence• Attack:
• XSS 101 for dummies...
• <script>alert('xss');</script>
• Defence:• sInput.Replace("<script>", "<script>“)
• Comments:• Poor choice – only replacing the “<script>” tag is too
specific, there are many ways around...
XSS Attack and Defence• Attack:
• So if they’re checking for “<script>” we’ll change it...• <ScRiPt>alert(‘XSS’);</ScRiPt>
• Defence:• OK – ToLower() should fix that...
• Comments:• Still very easily bypassed.
XSS Attack and Defence• Attack:
• Try something other than “script”• <IMG onmouseover="javascript:alert('XSS')"
SRC="http://www.aurasoftwaresecurity.co.nz/images/Logo.jpg">
• Defence:• Replace a larger set of strings...
• Comments:• So it picks up on of the recognisable text, but what
about encoded values?
XSS Attack and Defence• Attack:
• Perhaps HEX or UTF8 encoded• <IMG
onmouseover="javascript:alert('XSS')” SRC="http://www.aurasoftwaresecurity.co.nz/images/Logo.jpg">
• Defence:• HEX decode, then replace a larger set of strings...
• Comments:• So it picks up on of the recognisable text, even
encoded...But couldn’t it be simpler?
XSS Attack and Defence• Attack:
• Any variation...
• Defence:• http://www.owasp.org/index.php/XSS_%28Cross_Site_S
cripting%29_Prevention_Cheat_Sheet
• Comments:• Now it picks up all HTML special characters, whether
encoded or not However, there are alternatives...
XSS Attack and Defence• Attack:
• Any variation...
• Defence:• Microsoft AntiXSS Library (for .Net)
• Comments:• All done for you, and seems to work!
XSS Attack and Defence• Attack:
• So the web-pages are secure – what about the web-services?
• Defence:• Copy input cleansing to web-service, or move to data-
layer. Picks up data entry points.
• Comments:• It’s an option...
Etc, etc...
XSS Attack and Defence• Attack:
• So all web-services and web-pages are secure. Perhaps we’ve got in via a back-end legacy system?
• Defence:• Assume you cannot your own DB – cleanse the output
to the browser.
• Comments:• It’s an option...
XSS Attack and Defence• Attack:
• All data-stores, input and output are clean. So if persistant XSS fails try reflected.
• Defence:• Check EVERY input parameter, both on the querystring
and from form data!
• Comments:• Trust nothing, from anywhere!
Note: IE8 is blocking our reflected XSS! Good!
Unfortunately Firefox does NOT block our reflected XSS...
Encoding• Encoding is "the process of
transforming information from one format into another" [Wikipedia]
• Taking some input text and making it appropriate to use in a given context
• Untrusted input Safe to output• User enters: Kirk <script>...• We output: Kirk <script>....
Untrusted Input – 3 approaches
<script>alert('Hello!')</script>Input arrives:
Invalid input! Encode into DB Store verbatim
Display on web pageEncoded in DB
<script>alert(‘H
Store verbatim
<script>alert('Hello!’
<script>alert(‘H
<script>alert(‘H
Display directly Encode on display
Display contextsWhat if we want to display it in a
non HTML context?<script> var text = ‘XXXX’</script><a href=“http://foo.com/?XXXX”
class=“XXXX”>
Javascript context
URL context
HTML attribute context
XSS – Cross site scriptingDon’t display untrusted user input• Sanitise all input• Encode all output• HTTP Headers – don’t insert untrusted
content• Some ASP.NET controls don’t encode
output• Use Anti-XSS Library rather than HttpUtility
AntiXSS library• Encode text for a variety of contexts
• AntiXSS module for automatically encoding controls
• Produced by Microsoft ACE Team(Security, Performance and Privacy)
• Recently open-sourced (MS-PL, OSI apprv)
• White List character sets
• Principle of inclusions
• a-z, A-Z, 0-9, space, period, comma, underscore, hyphen
• Latin, Greek, Bengali, Balinese, Japanese, ...
AntiXSS Encoding MethodsYou determine the encoding method to use • HtmlEncode - html output, except when an
attribute• HtmlAttributeEncode - html attribute• JavascriptEncode - used within javascript,
puts inside quotes• UrlEncode - used in a url (e.g. query param)• ...and VisualBasicScriptEncode, XmlEncode,
XmlAttributeEncode
SRE - Security Runtime Engine
• Runs over entire page on pre-render• Looks at all controls, and all fields that
need encoding• Doesn’t double-encode• Add httphandler in web.config• Deploy in bin directory
Other tools• CAT.NET – static analysis of untrusted
data flows• SRE upcoming enhancements:
– SQL Detect – Clickjacking protection– File canonicalization– Securing cookies / enforcing SSL
Wrap Upo XSS attacks can be devastating – DO NOT
under-estimate.o If you’re vulnerable you WILL be attacked.o EASY TO FIX – at design and framework time.o BUGGER TO FIX – after you’ve written bad
code!o Pen-Test thoroughly o Keep up to date – OWASP is an excellent
source...