iLab2: WWW Security Johannes Naab <2019-03-15 Fri> Contents - - PDF document

iLab2: WWW Security

Johannes Naab∗ <2019-03-15 Fri>

Contents

1 WWW Basics 1 2 Security 2 3 Attacks 3 4 Defenses & Mitigation 5 5 Reporting Vulnerabilities 7

1 WWW Basics

• reading mails
• chatting on facebook
• checking news
• TUMonline for grades
• Video conference
• Changing the WiFi Password on the "Router"
• all within the same browser

1.1 HTML 1.2 HTTP

1.2.1 Header, Body 1.2.2 Request, Response 1.2.3 GET vs POST 1.2.4 Stateless 1.2.5 Persistent connections 1.2.6 Encryption HTTPS

1.3 Cookies 1.4 Session

• cookies ./. session

sessid=12345678 ilab.net.in.tum.de/?sid=1234567

∗naab@net.in.tum.de

1

1.5 Authentication

• session vs HTTP Auth

1.6 Java Script

• javascript is everywhere, not only in <script> Tags
• https://blog.twitter.com/2010/all-about-the-onmouseover-incident

1.7 Web Applications

1.7.1 Browser (User) 1.7.2 Web Server

• Apache, nginx, tomcat

1.7.3 Web Application (Frontend)

• PHP, Ruby, Python, Perl, C/Shell (CGI), Java
• 1. Frameworks

1.7.4 Database (and other Backend Services)

• MySQL, Memcached, Redis, Postgres, Oracle etc.

1.7.5 Middle Boxes

• (Reverse) Proxies
• "Security" Proxies

1.7.6 Backend Processes

• image processing
• pdf extraction/generation
• xml

– external entities 1.7.7 everything is/has an attack surface

2 Security

2.1 Why would somebody want to attack your $WEBSITE, and why should you care?

2.1.1 Attack against you application/website (for the lulz and the giggles, DoS, extortion)

• destruction of data
• Nice online shop you got there. It’d be a shame if anything were to . . . happen to it.

2.1.2 Privilege Escalation in your application

• 1. Seeing other data
• 2. having extra permissions

(a) Changing prices (b) banning people (c) access to admin panel

• to inject raw html for other attacks

2

2.1.3 Take over of resources for e.g. spamming, hosting a Botnet C&C server

• Your server has processing power, network resources etc.
• They are not in the attackers name.

2.1.4 inject malware/driveby downloads for your users

• You website could be (via JS) attack your users routers. https://www.google.com/search?q=router+

remote+command+injection+system 2.1.5 Stealing information from users

• not via server
• like Browser History

2.1.6 (http-based) DoS attacks against other websites by embedding resources 2.1.7 Exfiltation of Data (SQL Injection, Direct Linking)

• attack against you and/or your users
• insecure password storage

– yes, your website is not important – but users will reuse their passwords! 2.1.8 Exploitation of Trust

• URL shortener/Frame embedding
• Links to Paypal which redirect you to a phishing site

2.1.9 Your "users" want to get $STUFF for free from you $SHOP 2.1.10 "Cyber" Crime (as a Service)

2.2 Leave it to the users?

2.2.1 Modern Browsers can help, but they can’t solve everything 2.2.2 You need to configure/instruct them to use secure methods! 2.2.3 Maybe your users cannot update their browser and still use Windows XP 2.2.4 You users don’t care about your $WEBSITE, resources etc.

2.3 Same Origin Policy

• otherwise nothing else will work
• JavaScript can only read data from the same protocol + domain + port
• Why is this absolutely necessary?

3 Attacks

3.1 Injections of any kind

• breaking the interpretation context of data

3

3.1.1 SQL SELECT user, permissions from users where username = "$_POST[username]" and password= "$_POST[password]"; select login from users where username="$USERNAME" and password="$PASSWORD"; with USER a" or 1=1 -- select login from users where username="a" or 1=1 http://xkcd.com/327/

• 1. Blind SQL injection: infer information only by success/error -> binary search

3.1.2 XSS

• 1. reflected
• browser might filter trivial attempts

– but your users might still be on IE6

• 2. persistent

3.1.3 Header 3.1.4 Command Injection

• ; rm -rf –no-preserve-root /
• Shellshock
• Mail Form: mail addresses with newline can lead to your host being used to send spam

3.2 File Inclusion

• ../../../../../../../etc/passwd
• using arguments as filename
• The path is user input, and thus untrusted!

3.3 Session Fixing/Session Stealing 3.4 CSRF

• like installing mail filters/forwards in Gmail
• http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/
• https://web.archive.org/web/20100419130258/http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-

3.5 Information extraction

• check remote content onerror handler "escaping" the same origin policy
• PoC to detect Login/Account on social networks https://robinlinus.github.io/socialmedia-leak/

3.6 Layer 7 DoS attack

• deep linking/search queries

4

3.7 Algorithmic Complexity Attack

• your hash map of url parameters get turned into a linked list
• https://www.usenix.org/legacy/event/sec03/tech/full_papers/crosby/crosby_html/

3.8 MITM attacks

• ad injection, on a "free" hotspot

3.9 Stealing databases from developers

I’ll simply run the app only on localhost! http://bouk.co/blog/hacking-developers/ 3.9.1 connecting to IRC/sending real mail (without webserver) for data exfiltration (cross pro- tocol scripting) http://www-archive.mozilla.org/projects/netlib/PortBanning.html https://www.jochentopf.com/hfpa/ hfpa.pdf

• and bugs which avoid such restrictions: Safari browser port blocking bypassed by integer overflow

3.9.2 connecting/configuring the "router", "IoT" devices, etc in the local network

3.10 OWASP

• https://www.owasp.org/index.php/Top_10_2017-Top_10

3.11 Spectre / Meltdown

4 Defenses & Mitigation

4.1 Never trust the user

4.1.1 ever http://alicebobandmallory.com/articles/2010/09/23/did-little-bobby-tables-migrate-to-sweden 4.1.2 All user input is evil Like HTML Forms, where the user selects the purchase price in th shopping chart 4.1.3 Validate user input

• on the server!
• javascript executed by the client is untrusted
• 1. why would you "save" the price in the cart?
• prices can be updated along the way . . .

4.2 secure platform, proper templating

• no string concatination, use templates
• no SQL concatination, use prepared statements

4.3 CSP: Content Security Policy

s = document.createElement("script") s.innerHTML="alert(document.cookies)" document.body.appendChild(s)

• http://research.zscaler.com/2011/11/facebook-anatomy-of-self-inflicted.html
• https://github.com/tumi8/

5

4.3.1 Don’t allow all JS to run, but only from selected hosts

• no more "onerror" or <script> handler

4.4 SRI (sub resource integrity)

• http://www.w3.org/TR/SRI/
• CDNs can no longer (unintentionally) inject JS

4.5 Sandboxing, Framing options

• if you need to embed content

4.6 Use browser features like CSP, SRI, HSTS

• but you need to enable them

4.7 HTTP Cookies

4.7.1 secure 4.7.2 http only 4.7.3 FYI: Cookies are user input, don’t trust them!

• especially not to store for which domain an SSL Certificate should be issued

4.7.4 Cookie Integrity? https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng

4.8 Invalidate Session on the server

So the user can really log out

4.9 Bug/Features/Know your platform

4.9.1 e.g. duplicate query/post parameters

• google.com/search?q=123&q=456

4.9.2 sanatizing is hard

• 1. especially blacklisting <img onerror="alert(1)" src="does.not.exist">

4.9.3 Don’t expose the debugger/db/$foo in production

• http://labs.detectify.com/post/130332638391/how-patreon-got-hacked-publicly-exposed-werkzeug
• https://cispa.saarland/wp-content/uploads/2015/02/MongoDB_documentation.pdf
• X-forwarded-for: 127.0.0.1

4.9.4 default admin users/passwords 4.9.5 attacks are scripted, and start to exploit "zero" days fast

• keep your plattform/framework etc updated

6

4.9.6 trivia

• did you know that domain names can contain \0?
• did you know that Emails can contain multiple @, or < and >?

– http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses

• Some files are valid for multiple kind of content (zip, jpeg, etc) https://corkami.googlecode.com/svn/

trunk/src/angecryption/slides/AngeCryption.pdf

• UTF-7 Encoding http://openmya.hacker.jp/hasegawa/security/utf7cs.html
• any JS can be written with only ()+[]! http://www.jsfuck.com/
• 42.zip, archive bombs

– http://en.wikipedia.org/wiki/Zip_bomb – http://www.hackerfactor.com/blog/index.php?/archives/762-Attacked-Over-Tor.html (zip bombs for defense, or what you have to consider when processing responses)

• XML Billion Laughs Attack

– http://en.wikipedia.org/wiki/Billion_laughs – also works with git repos

• \ is a valid filename, so is ’ or , or or . . . <>

4.10 HTTPS, HSTS

nuff said

5 Reporting Vulnerabilities

7