application security in the real world what the owasp top 10 means to everyone
Post on 25-Feb-2016
32 Views
Preview:
DESCRIPTION
TRANSCRIPT
Lora Vaughn McIntoshSecurity EngineeringBlue Cross Blue Shield of AlabamaLora.McIntosh@bcbsal.org(205)220-2181
APPLICATION SECURITY IN THE REAL WORLDWHAT THE OWASP TOP 10 MEANS TO EVERYONE
About Me• BS Computer Science from Birmingham-Southern College• Formerly employed at Accenture, National Security Agency, Regions Bank • Certifications:• Certified Information Systems Security Professional (CISSP)• EnCase Certified Examiner (EnCE)
Agenda•What’s an OWASP?•Why should I care?• Security myths• Hacks in the news• OWASP Top 10 in 10 minutes or less• Legacy and third party applications• Defense in depth•Where do you start?
OWASP Who???• Open Web Application Security Project• 501c3 not-for-profit • Focused on improving the security of application software• Release Top 10 List periodically• 2010• 2007• 2004
APPLICATION SECURITY:
WHY SHOULD I CARE?
6
Progress—You can’t have it all• Business demands more
bells and whistles• Internal applications get
‘web-enabled’ and are exposed to Intranet or Internet• Increasing complexity of
software• Rush software out without
adequate testing• Poor security training and
awareness
7
Things Have Changed• Threats have evolved as the Internet and our world have evolved
• Any website you visit could infect your browser—even a Google search
• An infected browser can do anything you can do
• An infected browser can scan, infect, spread
Source: owasp.org
8
Regulations • If you’re lucky enough to
NOT need to meet• PCI• SOX• HIPAA• GLBA• Etc….
That’s nice, BUT what about• Your proprietary data?• Customer confidence?• Impact to operations?• Data integrity?
You still need to consider security. Period.
After all, you may just be one congressional session way from a new regulation.
9
So What???• Defacement• Phishing• Denial of Service• Data Loss• Bot Infection• Loss of <fill in the blank>• Legal action• ...
See the Web Hacking Incidents Database onhttp://www.webappsec.org/projects/whid/
How about I throw some money at the problem? Buy some tools!
10
OK, YOU’VE GOT ME THERE…
11
Well…. Tools Can’t Fix Everything• MITRE found that all application
security tool vendors’ claims put together cover only 45% of the known vulnerability types (over 600 in CWE)
• They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true)
Source: owasp.org
12
Great…
BUT I HAVE OTHER CONTROLS!
SECURITY MYTHS
The Trouble with Firewalls
Joe User says: “But we have a firewall”!
75% of Internet Vulnerabilities are at the application layer, not the network layer
- Gartner
Firewalls have to allow some things through, and attackers have adapted.
Source: Jeremiah Grossman, BlackHat 2001
The Trouble with Firewalls Illustrated
Source: owasp.org
But… But… We use SSL!• SSL only secures data in transit• Does not solve vulnerabilities on:• Applications• Web server• Browser• If you exploit the application, any data at rest encryption is
useless too.
16Source: Jeremiah Grossman, BlackHat 2001
SSL Illustrated
Source: owasp.org
17
Myth – my perimeter will save me
Firewall
Hardened OSWeb ServerApp Server
Firewall
Dat
abas
esLe
gacy
Sys
tem
sW
eb S
ervi
ces
Dire
ctor
ies
Hum
an R
esrc
sB
illin
gCustom Developed Application Code
APPLICATIONATTACK
You can’t use network layer protection (firewall, SSL, IDS, hardening) to stop or detect application layer attacks
Net
wor
k La
yer
App
licat
ion
Laye
r
Your security “perimeter” has huge holes at the application layer
Source: owasp.org
Real Life Application (?) Hacks• CitiGroup• May 2011 • Approximately 210,000 credit card holders• “Basically after you logged into your account as a Citi customer, the URL
contained a code identifying your account. All you had to do was change around the numbers and boom, you were in someone else's account”
• StuxNet• Targeted Siemens SCADA systems of Iranian nuclear facilities• Stolen encryption keys used to sign infected drivers• Zappos • January 2012• 24+ Million customer accounts• Name, e-mail, billing and shipping addresses, phone numbers, last 4 of credit
card, encrypted passwords• TJ Maxx• 2007• 45.7 million credit/debit cards
OWASP TOP 10 IN 10 MINUTES OR LESS
OWASP Top 10 Risk Rating Methodology
ThreatAgent
AttackVector
Weakness Prevalence
Weakness Detectability Technical Impact Business
Impact
?Easy Widespread Easy Severe
?Average Common Average ModerateDifficult Uncommon Difficult Minor
1 2 2 1
1.66 * 1
1.66 weighted risk ratingInjection Example
123
Source: owasp.org
OWASP Top Ten (2010 Edition)A1: Injection
A2: Cross-Site Scripting
(XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross Site Request Forgery (CSRF)
A6: Security Misconfigurat
ion
A7: Failure to Restrict URL
Access
A8: Insecure Cryptographi
c Storage
A9: Insufficient Transport
Layer Protection
A10: Unvalidated
Redirects and Forwards
http://www.owasp.org/index.php/Top_10
Source: owasp.org
A1 – Injection• Tricking an application into including unintended commands in
the data sent to an interpreter
Injection means…
• Take strings and interpret them as commands• SQL, OS Shell, LDAP, XPath, Hibernate, etc…
Interpreters…
• Many applications still susceptible (really don’t know why)• Even though it’s usually very simple to avoid
SQL injection is still quite common
• Usually severe. Entire database can usually be read or modified• May also allow full database schema, or account access, or even
OS level access
Typical Impact
Source: owasp.org
23
SQL Injection• A common issue in most applications• Can only occur when the application is building dynamic SQL that contains a string that is tainted with user supplied data
http://xkcd.com/327/
24
SQL Injection in the Wild
A2 – Cross-Site Scripting (XSS)
• Raw data from attacker is sent to an innocent user’s browser
Occurs any time…
• Stored in database• Reflected from web input (form field, hidden field, URL, etc…)• Sent directly into rich JavaScript client
Raw data…
• Try this in your browser – javascript:alert(document.cookie)
Virtually every web application has this problem
• Steal user’s session, steal sensitive data, rewrite web page, redirect user to phishing or malware site
• Most Severe: Install XSS proxy which allows attacker to observe and direct all user’s behavior on vulnerable site and force user to other sites
Typical Impact
Source: owasp.org
26
XSS In The Real World
A4 – Insecure Direct Object References
• This is part of enforcing proper “Authorization”, along with A8 – Failure to Restrict URL Access
How do you protect access to your data?
• Only listing the ‘authorized’ objects for the current user, or
• Hiding the object references in hidden fields• … and then not enforcing these restrictions on the
server side• This is called presentation layer access control, and
doesn’t work• Attacker simply tampers with parameter value
A common mistake …
• Users are able to access unauthorized files or data
Typical Impact
Source: owasp.org
Insecure Direct Object References Illustrated
• Attacker notices his acct parameter is 6065
?acct=6065
• He modifies it to a nearby number
?acct=6066
• Attacker views the victim’s account information
• Look familiar???
https://www.onlinebank.com/user?acct=6065
Source: owasp.org
A5 – Cross Site Request Forgery (CSRF)
• An attack where the victim’s browser is tricked into issuing a command to a vulnerable web application
• Vulnerability is caused by browsers automatically including user authentication data (session ID, IP address, Windows domain credentials, …) with each request
Cross Site Request Forgery
• What if a hacker could steer your mouse and get you to click on links in your online banking application?
• What could they make you do?
Imagine…
• Initiate transactions (transfer funds, logout user, close account)• Access sensitive data• Change account details
Typical Impact
Source: owasp.org
A6 – Security Misconfiguration• Everywhere from the OS up through the App Server• Don’t forget all the libraries you are using!!
Web applications rely on a secure foundation
• Think of all the places your source code goes• Security should not require secret source code
Is your source code a secret?
• All credentials should change in production
CM must extend to all parts of the application
• Install backdoor through missing OS or server patch• XSS flaw exploits due to missing application framework patches• Unauthorized access to default accounts, application functionality
or data, or unused but accessible functionality due to poor server configuration
Typical Impact
Source: owasp.org
A7 – Insecure Cryptographic Storage
• Failure to identify all sensitive data• Failure to identify all the places that this sensitive data
gets stored• Databases, files, directories, log files, backups, etc.
• Failure to properly protect this data in every location
Storing sensitive data insecurely
• Attackers access or modify confidential or private information• e.g, credit cards, health care records, financial data (yours or
your customers)• Attackers extract secrets to use in additional attacks• Company embarrassment, customer dissatisfaction, and loss
of trust• Expense of cleaning up the incident, such as forensics,
sending apology letters, reissuing thousands of credit cards, providing identity theft insurance
• Business gets sued and/or fined
Typical Impact
Source: owasp.org
A8 – Failure to Restrict URL Access
• This is part of enforcing proper “authorization”, along with A4 – Insecure Direct Object References
How do you protect access to URLs (pages)?
• Displaying only authorized links and menu choices• This is called presentation layer access control, and
doesn’t work• Attacker simply forges direct access to ‘unauthorized’
pages
A common mistake …
• Attackers invoke functions and services they’re not authorized for
• Access other user’s accounts and data• Perform privileged actions
Typical Impact
Source: owasp.org
A9 – Insufficient Transport Layer Protection
• Failure to identify all sensitive data• Failure to identify all the places that this sensitive data is
sent• On the web, to backend databases, to business partners, internal
communications• Failure to properly protect this data in every location
Transmitting sensitive data insecurely
• Attackers access or modify confidential or private information• e.g, credit cards, health care records, financial data (yours or your
customers)• Attackers extract secrets to use in additional attacks• Company embarrassment, customer dissatisfaction, and
loss of trust• Expense of cleaning up the incident• Business gets sued and/or fined
Typical Impact
Source: owasp.org
A10 – Unvalidated Redirects and Forwards
• And frequently include user supplied parameters in the destination URL
• If they aren’t validated, attacker can send victim to a site of their choice
Web application redirects are very common
• They internally send the request to a new page in the same application
• Sometimes parameters define the target page• If not validated, attacker may be able to use unvalidated
forward to bypass authentication or authorization checks
Forwards (aka Transfer in .NET) are common too
• Redirect victim to phishing or malware site• Attacker’s request is forwarded past security checks, allowing
unauthorized function or data access
Typical Impact
Source: owasp.org
35
What about…
LEGACY APPLICATIONS
36
Legacy Application ProblemsOld Frameworks + Old Code + Old Vulnerabilities
= Low hanging fruit
We didn’t even know about some of these attacks 10 years ago
How old are your apps?
37
Don’t forget 3rd Party Apps• Think • Frameworks• HR software• Data analytics tools• Cloud
38
So…
WHERE DO YOU START???
39
Defense in Depth• Multiple layers of protection reduces the likelihood that an attacker will be successful• Firewall, IDS, etc? Useful technologies, but not as your sole defense• Penetration testing• Code analysis• Security training for your developers
40
Write secure code in the first place• Build procedures into the process to mitigate risk (SDLC)• Create standards that will assist in answering FAQs• Libraries and best practices for coding• Follow the best practices in OWASP’s Guide to Building Secure Web
Applications• http://www.owasp.org/index.php/Guide• Use OWASP’s Application Security Verification Standard as a guide to
what an application needs to be secure• http://www.owasp.org/index.php/ASVS• Use standard security components that are a fit for your organization• Use OWASP’s ESAPI as a basis for your standard components• http://www.owasp.org/index.php/ESAPI
Don’t reinvent the wheel. If you try to write your own cleansing functions, you WILL miss something. Unless you’re a coding God, but even then…
41
But that ship already sailed, so…Know your data• What data do you care about?• Regulations help – PCI, GLBA, HIPAA• Proprietary data—What’s your “secret sauce”?• What types of data do you have?• Where is that data?• Is it encrypted? Should it be?• How about backups?• Are you sure it’s not sitting on Susan’s workstation because “it’s
easier if I don’t have to log on to the server”?• Who has access to that data?• Should they have access to it?• What happens when they change roles or jobs?
42
Baby Steps - Policy• State that you intend to write secure code• Policy for remediating legacy code• Get security into the overall procurement and development
cycle
43
Baby Steps - Standards• Incorporate secure development standards (Start with
OWASP?)• Require minimums• In the lifecycle, get stop points in place – QA cycle?
44
Baby Steps - Procedures• Pre-deployment checklists--a low cost approach to building
application security in• Code reviews• Formal application security testing• Remediation plans
Tools and Services• Review Your Applications• In house manual code review• Not a bad idea, but how many of your developers know the ins and outs
of every single application vulnerability and exploit?• Application assisted static code analysis• Look into products like HP Fortify, Rational, Veracode, etc.• Most of these offer cloud and local solutions• Large amounts of tuning required to make sure your environment is reflected
• Have an expert team or service review your applications• Review your applications yourselves following OWASP Guidelines• OWASP Code Review Guide:
http://www.owasp.org/index.php/Code_Review_Guide • OWASP Testing Guide:
http://www.owasp.org/index.php/Testing_Guide
46
Options: Web Application Firewalls• Can you spend the money?• Do you have the staff to manage one?• OWASP has great resources on when and where to use them
47
Code Analysis• Dynamic, static, or both?• Each type can miss things• A combination is probably best, but can be costly• On premise, hosted, or hybrid?• Do you have the staff to implement?• Plans to remediate findings?
48
Tools… again• Vendors• Accunetix • Cenzic• HP Fortify• IBM• Veracode• Open Source (free or lower
cost)• WebScarab• Nikto• Paros
• Vendors• Coverity • IBM • HP Fortify• Veracode• Open Source (free or lower
cost)• FindBugs (Java only)• Other options, but mostly
targeting specific vulnerabilities like
Dynamic Analysis Static Analysis
49
You have tools – now what???• Back to the people side• Sell it (much easier if you have regulations behind you)• Training• User• Administrator• Team to administer• Audit • Make sure developers are following procedures and using the tool• Ensure new vulnerabilities aren’t added – think “No new critical flaws”
• Reporting• Can save you in an audit• Good place for metrics• . . . • Profit!!!
Source: owasp.org
50
QUESTIONS?
top related