FIT5003 Software Security
Web Security I
1
FWITe5b0S0e3cSuoriftywOavrerSveiecuwrity
• Web applications: Very popular, but difficult to secure • Highly connected: opportunities for hackers!
• Lots of technologies: more opportunities!
• This module (this week and next):
• Overview of Web Technologies
• Server side, browser side
• Web Application threat model & Same Origin Policy
• Common Web app. Vulnerabilities & Defenses
• SQL Code injection (SQLi)
• Cross-Site Scripting (XSS)
• On-Site/Cross-Site Request Forgery (OS/CSRF) • Session Management / Authentication
• Other issues
2
Web Technologies
FWITe5b0S0e3cSuoriftywOavrerSveiecuwrity
3-Tier Web Architecture: Client-Server-Database
Interface tier
Logic tier
Storage tier
Client Web Browser
(IE, Chrome, Firefox,… )
HTTP / HTTPS
Javascript, VBScript, DOM/Ajax/ JSON/XML, browser extensions: Java applets, ActiveX,Flash,Silverlight,
…)
SQL, SOAP /XML,…
Browser script (HTML / HTML5, CSS,
Server Script (PHP, Java,
ASP.NET, Python, Perl, …)
Database language
(MySQL, MS-SQL,
Oracle, …)
Web Server
(IIS, Apache, …)
Database / Backend server
(MySQL, MS-SQL, Oracle, …)
3
Web Technologies
FWITe5b0S0e3cSuoriftywOavrerSveiecuwrity
• We will (very) briefly overview some important web technologies
• Basics of HTTP:
• URLs/ requests / responses / cookies
• Server side:
• PHP scripting
• SQL database queries
• Browser:
• HTML , Javascript:
• Document Object Model (DOM)
• Browser security policy: Same origin policy
4
HTML (HyperText Markup Language) FIT5003 Software Security
➢ HTML is presented for publishing hypertext on the World Wide Web
➢ Define tags
➢ Allow to embed other scripting languages to manipulate
design layout, text and graphics
➢ Platform independent
➢ For more info: http://www.w3.org/MarkUp/
55
HTML (HyperText Markup Language) FIT5003 Software Security
66
HTML (HyperText Markup Language) FIT5003 Software Security
77
HTML (HyperText Markup Language) FIT5003 Software Security
88
HTML (HyperText Markup Language) FIT5003 Software Security
https://www.w3schools.com/html/tryit.asp?filename=tryhtml_default
99
CSS (Cascading Style Sheet) FIT5003 Software Security
➢CSS is a style sheet language used to determine the formatting of an HTML document.
➢Before we had CSS (and before it was widely adopted) all of this formatting information was embedded directly in the document- either in the form of attributes like width or bgcolor (background color) or in the form of purely presentational tags like font.
10 10
CSS (Cascading Style Sheet) FIT5003 Software Security
➢Combined with the abuse of the table tag to create complicated layouts, the landscape for layout and design on the web was an unmanageable mess.
➢Using separate style sheets for an entire site, leveraging semantic markup and identifiers like ids (for unique page elements) and classes (for multiple, like elements) a developer can apply styles across a whole site while updating a single (cacheable) file.
11 11
CSS (Cascading Style Sheet) FIT5003 Software Security
➢ Simple mechanism for adding style to web page ➢ Code be embedded into the HTML file
➢ HTML tag:
➢ Also can be in a separate file FILENAME.css ➢ HTML tag:
➢ Style types mainly include:
Font Color Spacing
12 12
CSS (Cascading Style Sheet) FIT5003 Software Security
13 13
CSS (Cascading Style Sheet) FIT5003 Software Security
14 14
Javascript
FIT5003 Software Security
➢ A lightweight programming language (“scripting language”) ➢ used to make web pages interactive
➢ insert dynamic text into HTML (ex: user name)
➢ react to events (ex: page load user click)
➢ get information about a user’s computer (ex: browser type)
➢ perform calculations on user’s computer (ex: form validation)
15 15
Javascript
FIT5003 Software Security
+ ➢interpreted, not compiled
=
➢more relaxed syntax and rules ➢fewer and “looser” data types ➢variables don’t need to be declared ➢errors often silent (few exceptions)
➢contained within a web page and integrates with its HTML/CSS content
16
Javascript
FIT5003 Software Security
alert(“IE6 detected. Suck-mode enabled.”);
JS
17 17
Javascript
FIT5003 Software Security
18 18
Javascript
FIT5003 Software Security
19 19
Javascript
FIT5003 Software Security
20 20
Javascript
FIT5003 Software Security
21 21
FWITe5b0S0e3cSuoriftywOavrerSveiecuwrity
HTTP
• General Format: protocol://hostname[:port]/[path/]filename[?param=va
lue]][#fragment_id]
“REST style URLs”: contain parameters in the URL file path in the form ?param1=val1[¶m2=val2…]
Examples:
http://moodle.vle.monash.edu/course/view.php?id=18476 http://www.ninemsn.com.au/?pc=UP97&ocid=UP97DHP
22
FWITe5b0S0e3cSuoriftywOavrerSveiecuwrity
• HTTP protocol: message-based model • Client sends a request message
• Server returns a response message
• HTTP Requests
• one or more headers (each on a separate line) • Blank line
• (optional) message body
• Two most imporant types of request “methods”:
• GET (no message body, any parameters passed in URL): retrieve resources
• POST (both message body and URL can contain parameters): perform action
• Typical request message:
GET /auth/488/details.ashx?uid=129 HTTP/1.1
Accept: image/png, image/svg+xml, image/*;q=0.8, */*;q=0.5
Referer: http://www.ninemsn.com.au/?pc=UP97&ocid=UP97DHP
Accept-Language: en-AU
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64;
Trident/6.0)
Accept-Encoding: gzip, deflate
Host: ping.chartbeat.net
Proxy-Connection: Keep-Alive
Cookie: SessionID=5B70C71F3FD4968935CDB6682E55476
23
HTTP Responses
FWITe5b0S0e3cSuoriftywOavrerSveiecuwrity
• HTTP Responses
• one or more headers (each on a separate line) • Blank line
• Message body: usually HTML page
• Typical response message:
HTTP/1.1 200 OK
Server: Bunny-Server/0.9.2
Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc Content-Type: text/html; charset=utf-8 Content-Length: 1070
24
HTTP: Cookies
FWITe5b0S0e3cSuoriftywOavrerSveiecuwrity
• Plain HTTP is a stateless protocol • Each request/response is independent
• But many applications need user sessions
• E.g. buying session on Amazon.com
• Server needs to store session context (server state) , e.g. what was bought
• Server needs to detect which session a request comes from (session ID) →need client state to store session ID
• Cookies: HTTP mechanism for client to store state • POST
POST …
// A logging in to Amazon
HTTP Response Header:
200 OK …
Set-Cookie: tracking=tI8rk7joMx44S2Uu86nSWc
// Amazon sets up Li’s session
POST …
Cookie: tracking=tI8rk7joMx44S2Uu86nSWc
// A buys book “Web Hacking Handbook”
HTTP Response:
200 OK …
// Hello again, A. Thanks for buying!
Store:
URL: Amazon.com
cookie:
tracking=tI8rk7joM
x44S2Uu86nSWc
Client Web Browser (A)
Store:
A’s session
cookie:
tracking=tI8rk7joM
x44S2Uu86nSWc
Server (Amazon.com)
Check cookie:
It’s A’s session!
25
FWITe5b0S0e3cSuoriftyw(aSrervSercuSirditey)
• Server side programming languages: • PHP, ASP.NET, Java Platform,…
• General purpose languages for implementing web application logic: • Generate dynamic page content
• Create, open, read, write, delete, and close files on the server
• Collect form data
• Send and receive cookies
• Add, delete, modify data in your database
• Restrict users to access some pages on your website • Encrypt data
• ….
• Runs on server and outputs HTML page for browsers
26
FWITe5b0S0e3cSuoriftyw(aSrervSercuSirditey)
Server Side: Database Query Languages
• Structured Query Language (SQL)
• Variants: Oracle, MS-SQL, MySQL
• SQL manages relational databases:
• Database consists of tables
• Each table has a number of rows (database records) , e.g. a row per user
• Each row has a number of columns (data fields), e.g. “email address”, “name”, “age”,…
• SQL language queries: read, update, add, or delete data
• E.g. SELECT email FROM users WHERE name = ‘Li’
• Returns email column value for rows in users table where the name column value = ‘Li’. 27
FWITe5b0S0e3cSuoriftyw(aBrreowSesceurrSitiyde)
Client Side: Browser Security Policy
• Browser security goals:
• User can safely visit any web site
• Even malicious web sites cannot access / modify client’s local disk / memory information without user’s permission
• Browser runs Javascript in a sandbox – access OS / file system via API enforcing access control
• E.g. Upload authorization via file picker dialog.
• However, a web site can still track users (e.g. cookies,…)!
• User can safely visit multiple web sites in same browser:
• Open page from site X cannot interfere (read/write) with open page
from site Y
• E.g. banking site window should not be read by script in social networking window
• Enforced via the browser Same Origin Policy
28
FWITe5b0S0e3cSuoriftyw(aBrreowSesceurrSitiyde)
• Browser Same Origin Policy principle:
• •
• Content from page X in browser is allowed to access (read/write) page Y in browser only if the pages are hosted on the same site (domain) and using the same protocol.
• E.g. X URL = http://monash.edu/IT/staff.html ,
• Y URL = http://monash.edu/ENG/staff.html : allowed
• Y URL = http://www.attacker.com/atk.html : not allowed • Y URL = https://monash.edu/ENG/login.html : not allowed
Prevents malicious web sites from directly injecting script into client browsers to compromise concurrent sessions
But, some potential issues in practice:
•
Page X on one domain in browser, can still issue a request to any other domain (but cannot process the response).
• Information leakage threat: user has to trust script from server not to send information to other sites
• When combined with other vulnerabilities, can lead to attacks on user’s session with server X even if X is honest!
• E.g. Cross-site scripting / request forgery vulnerabilities (later!)
29
FWITe5b0S0e3cSuoriftyw(aBrreowSesceurrSitiyde)
• Browser security policy — potential practical issues (cont.):
• Malicious server impersonating real server
• Alice browses my.monash.edu via a café Wi-fi wireless link • Receives response from http://my.monash.edu
• Enters her username and password to login
• Her credentials are stolen (http, not https)!
• Issue: Browsers by default accept http response (do not know if it should be https or not)
• Solution:
• HTTP Strict Transport Security (HSTS) flag (enforced by the server):
• At Alice’s first visit to my.monash.edu, my.monash web app. sets HSTS flag in Alice’s browser: forces https for subsequent browser visits to my.monash (refuse connection with http).
Header: Strict-Transport-Security
30
FWITe5b0A0p3pSoTfhtrwearteMSoedcuerl ity
Web Application Threat Model
• Threats on server Web applications: • Attacks on Server side:
• Attack setting: Attacker interacts as web app client with server web application
• Goal: Inject attacker code to modify web app behavior on server
• Common Vulnerability: SQL code injection
• Attacks on Client side:
• Attack setting:
• (1) Malicious web app client attacking another web app client
• (2) Malicious web server attacking a web app client
• Goal: Inject attacker script into target client web browser to attack client’s
interaction with web app.
• Common Vulnerability: Cross-Site Scripting (XSS)
31
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• SQL Injection:
• Lack of user input validation vulnerability
• Allows attacker to directly inject SQL code into SQL database
server
• Often gives attacker complete control!
• Demo: https://www.youtube.com/watch?v=h- 9rHTLHJTY
• How users are supposed to behave?
Honest Authorised user’s “proper” behaviour Name: john
Password: monkey
Misbehaviour by ignorant attacker Name: john
Password: guess
Site rejects incorrect login password
32
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
Attack Example 1: Clever attacker’s misbehaviour Name: john’ —
Password:
Why does this work?
• Exploits knowledge of system “under the hood”:
• Login verification checked by server by passing a command
string to an SQL database interpreter
• Command string consists of a concatenation of SQL language
commands and user input data
• Attacker’s password input string contains both data (guess)
and commands (‘ –)!
• Attacker’s command string passed to SQL interpreter and
executed!
• Vulnerable due to invalid assumption by developer: assumed users will only enter alphabetic characters!
33
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
“Under the Hood”: Client-Server-Database Setup
Client
Client Web Browser (HTML)
Server Script (PHP)
Database interpreter (MySQL)
34
HTTP
SQL
Server
Database
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• “Under the Hood” : Vulnerable Server PHP code
$lUsername = $_REQUEST[“username”];
$lPassword = $_REQUEST[“password”];
$lQueryString = ” SELECT * FROM accounts WHERE
`
username=’ ” . $lUsername . ” ‘ AND
password=’” . $lPassword . “‘” ;
$lQueryStringResult = $MySQLHandler->executeQuery($lQueryString);
• Command string $lQueryString passed to SQL interpreter for honest user login (user=john, pwd=monkey):
SELECT * FROM accounts WHERE username=’john’ AND password=’monkey‘
• Command string $lQueryString passed to SQL interpreter for attacker login (user=john’ — , pwd=guess):
SELECT * FROM accounts WHERE username=’john’ — ‘ AND password=’guess’
• “–” interpreted by SQL server as “begin comment” command • ignores following “AND…” password check!
35
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• Control of SQL commands in the hands of attacker can lead to devastating attacks
• What if the hacker doesn’t know any user’s name? Wants to get ALL users info from Database?
• Attack Example 2: Clever attacker’s misbehaviour
• Name: bob’ OR 5=5 –-
• Password:
• Command string $lQueryString passed to SQL interpreter:
SELECT * FROM accounts WHERE username=’bob’ OR 5=5 — ‘ AND password=’guess’
• All DB entries satisfy username=’bob’ OR 5=5!
• Lesson: Server app must not pass user input blindly to SQL server
• Must ensure even malicious user input can not be interpreted as commands
•
Use SQL parameterized queries (more details later).
36
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• Why just modify existing SQL code?
• Injection Vulnerability allows attacker do even more damage by injecting
own code!
• Attack Example 3: Attacker own code injection
• Name: bob′ ; DROP TABLE accounts –- • Deletes the accounts table…
• Similarly, can insert new tables, users, …
• or even shutdown the whole database:
• Name: bob′ ; shutdown —
37
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• SQLi in the real world
• Open Web Application Security Project (OWASP) –
https://www.owasp.org has a top 10 list of web application vulnerabilities • Code injection is #1 in the 2013 top 10 list!
• A really big exploit example: • CardSystems Data breach (2005):
• CardSystems: company processed credit-card data for major vendors (Mastercard, VISA,…)
• Hackers accessed Cardsystems customer web app.
• Found SQLi vulnerability and injected code to:
• Run every four days: gather card data, zip it, and FTP to attackers • Three zip files were downloaded
• Over 40 million(!) unencrypted card details stolen
• VISA and Mastercard abandoned Cardsystems
• Cardsystems closed down!
38
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
39
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• LOTS of variants of SQLi exploits
• Can often be used to bypass simple SQLi countermeasures, such as
character escaping filters
• Bypassing simple SQLi filter countermeasures:
• In previous attacks, attacker needed to add ‘ character to terminate the data string and start entering commands
• What if the ‘ character is escaped by the application? E.g. Application can replace any occurrence of ‘ char by ‘‘.
40
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
Bypass example: Injection into numeric data
The application may also accept numeric user input data. Numeric data can be passed directly to database without ‘ quotes
E.g. for vulnerable code like
$lQueryString = ” SELECT * FROM
customers WHERE
customerID=” . $customerID;
– Attacker input: 1 OR 5=5 –- (no need for quote symbol)
41
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• Another method to bypass escaping: second-order SQLi
• Suppose ‘ character in user input string was escaped (replaced by
’’) by web application
A second-order vulnerability for string inputs may still be exploitable:
• Consider app registering users in database and then retrieving
• Attack first phase: attacker registers escaped input into database
• Attacker registers into database user name such as • bob‘ OR5=5–
• Due to escaping of ‘ character, this user name is processed correctly, and inserted into database
• No injected code execution in phase 1. But now the stored username string is bob‘ OR 5=5 — without escaping…
42
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
Attack second phase: As a registered user, attacker performs a password lookup function for himself
• Web app retrieves user’s name from database into a variable $username: resulting value of $username is bob‘ OR 5=5 –-
• Since username is retrieved from database and not from user input, no escaping is performed by application:
$lQueryString = ” SELECT password FROM accounts
WHERE username=‘” . $username . “’”;
• Executed query:
SELECT password FROM accounts WHERE
username=‘bob‘ OR 5=5 –-
– Now injected code is executed in second phase – all passwords
revealed!
Yet Another example: https://haiderm.com/second-order-sql-injection- explained-with-example/
43
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• How to defend effectively against SQLi?
• Filtering / escaping is tricky / can often be bypassed
• Preferred robust solution: parameterized queries
• A.k.a prepared statements
• Fix root cause of injection problem: SQL database treating user data as code
• Idea: Application passes the SQL statement to SQL server in two distinct phases:
• Phase 1 (pass code): Pass desired SQL statement with placeholders (? Symbol) for data values, e.g.
$stmt = $mysqli->prepare(“SELECT District FROM City WHERE name=?”);
• Phase 2 (pass data): Pass the data values for placeholders, e.g.: $stmt->bind_param(“s”, $name);
• Finally, execute and get result, e.g.:
•$stmt->execute(); /* This executes the prepared statement $stmt */ •$result = $stmt->get_result(); /* Get result into $result */ •$stmt->close(); /* This completes the prepared statement */
• Any malicious user data passed in Phase 2 will be interpreted as data, not code. 44
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• How to defend effectively against SQLi (cont.):
• Tips / pitfalls for using parameterized queries effectively:
• Use parameterized queries for every database query
• Don’t use it just for queries that directly process user input
• Remember the second-order SQLi attacks
• Malicious input can be stored and only later executed!
• Easy to misjudge which data is user-controllable: much safer
to use it for all queries!
• Remember to parameterize every query data item
• Even a single concatenated parameter can be used for injection!
45
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
Limitations of parameterized queries:
• Table and column names in a query cannot be parameterized
• If any chance of those names being user-controlled:
• Use a white list of acceptable values (e.g. list of known names
in database)
• If not possible, use a strict validation restriction (e.g. allow only alphanumeric characters, reject any spaces, and limit length)
• Other parts of query code also cannot be parameterized • E.g. SQL keywords like ASC (ascending) or DESC
(descending), as in queries like
SELECT * FROM Customers ORDER BY Country DESC;
• Use whitelists of valid options (e.g. ASC or DESC)
46
FSIQTL50In0j3ecStiofntwVualrneerSaebciluitriietsy
• Tips for testing for SQLi vulnerabilities:
• If reviewing code, look for SQL queries without prepare
statements
• If doing penetration testing, try:
• Entering single quote in a data input field
• If an error occurs (three quotes in SQL statement formed?), that is a good hint of a SQLi bug
• If entering two single quotes ’’ in a data input field eliminates error, confirms hint (escaping)
• Further test: try injecting code generating equivalent result (if interpreted as code), e.g.
• Does input ron give the same output as ‘ ‘ron ?
• Space allows string concatantion in MySQL
• Other databases have different syntax: e.g. ‘+‘ron for MS-SQL
• SQLi cheetsheet: https://www.netsparker.com/blog/web- security/sql-injection-cheat-sheet/
47