Transcript Top-Ten Web Security Vulnerabilities

10 – 12 APRIL 2005 Riyadh, Saudi Arabia
Web Application Security
Fundamentals
Murat Lostar
Information Security Consultant
“When we face a choice between adding new features and
resolving security issues, we need to choose security.
Our products should emphasize security right out of the
box”
Bill Gates
CIA Concept
Confidentiality
Information must be protected from unauthorized disclosure
Integrity
Information must be protected from unauthorized modification
Availability
Information must be available when the users need it
The goal of an attack
Steal data
Blackmail
Beachhead for other attacks
Bragging rights
Vandalism
Demonstrate vulnerability/satisfy curiosity
Damage company reputation
Designing Secure Systems
Designing Secure Systems
How much security does a web application
require?
Zero risk is not practical
There are usually multiple ways to mitigate risk
Don’t spend $ 1.000.000 to protect $ 0,1
Security is almost always overhead, either in cost or
performance
Designing Secure Systems
Common Security Mistakes
Security Principles
Security Design by Threat Modeling - STRIDE
Security Techniques
A Cornucopia of Threats and Solutions
Common Security Mistakes
Not designing applications with security in mind.
Adding security to the application as an afterthought.
This can be expensive than you think.
Adding security later,
Can change the way the features have been implemented
Can change the application interface
Can break the previously written code
Why these mistakes are
made?
Security is boring
Security disables some functionality.
Security is difficult to measure.
Security is not the interest of the designers and
developers creating the product.
Security Principles
Establish a Security Process
If you don’t define a process for designing, coding,
testing, deploying and fixing systems in a secure
manner, it’s very likely that you will spend a huge
amount of time fixing security bugs.
Consider Security as a Product Feature
Build and review the development plan.
Security Principles
Define the Product Security Goals
Who is the audience?
What does security mean to the audience?
Where will the application run?
What are you attempting to protect?
Who will manage the application?
What are the communication needs of the product?
What security infrastructure services do the OS and the
environment already provide?
Security Principles
Learn from Mistakes – Every bug is a learning
opportunity
How did the security error occur?
Is the same error replicated in other areas of code?
How could we have prevented this code from occurring?
How do we make sure this kind of error does not happen in the
future?
Use Least Privilege
What resources must your application access?
What special tasks must your application perform?
Security Principles
Use Compartmentalization (separation of privileges)
Separation between users, processes, data, and networks
helps contain problems if they occur.
Give the
Use Defense in Depth
Don’t rely on other systems to protect you
At some stage you (your software) have to defend yourself.
Implement a “default deny” stance
Security Principles
Assume External Systems Are Insecure
Until proved otherwise, all external stimuli have the potential to be an
attack.
Plan on Failure
Bugs happen
Make security contingency plan
Fail to a Secure Mode
The application has not disclosed any data that would not be
disclosed ordinarily, the data still can not be tampered with, ...
Do not issue huge swaths of information explaining why the error
occured. Give the user a little bit of information.
Here is an example:
Security Principles – Code
Example
...
DWORD dwRet = IsAccessAllowed(...)
if (dwRet == ERROR_ACCESS_DENIED) {
// Security check failed.
// Inform user that access id denied.
} else {
// Security check OK.
// Perform task.
}
....
Security Principles – Code
Example
...
DWORD dwRet = IsAccessAllowed(...)
if (dwRet == NO_ERROR) {
// Security check OK.
// Perform task.
} else {
// Security check failed.
// Inform user that access id denied.
}
....
Security Principles
Employ Secure Defaults
If a feature is not running, it cannot be vulnerable to attack
Another reason for not enabling features by default is
Performance.
Backward Compatibility Issue?
Be ready to face many upgrade and backward compatibility
issues if you change critical features (for security reasons.)
The weak version of the protocol lives forever.
Security Features = Secure Features ???
Security features do not necessarily make for a secure
application.
Security Principles
Never Depend on Security Through Obscurity
Always assume that an attacker knows everything
you know
Validate input and output
User input and output to and from the system is the
route for malicious payloads into or out of the
system
Allow only explicitly defined characteristics and drop
all other data
Security Principles
Keep it simple
Often the most effective security is the simples
security
If the steps to secure a function or module of the
application are too complex, they probably won’t be
followed
Complex code is hard to understand, makes
maintenance error-prone
Security Principles
Use and reuse trusted components
When someone else has proven they got it right,
take advantage of it
Beneficial from both a resource and security
perspective
Only as secure as the weakest link
Attackers will find the weakest point and attempt to
exploit it
Don’t leave all the locks on the front door and leave
the back door swinging open
Security Principles – Three
Final Points
If you find a security bug, fix it and go looking for
similar issues in other parts of the code.
If you find a security bug, make the fix as close
as possible to the location of the vulnerability.
If there is a fundamental reason why a security
flaw exists, fix the root of the problem. Don’t
patch it over.
An Example
Authentication
Data
Application Data
LDAP
Web
Browser
HTTP
Web Pages
Web
Server
DCOM
App.
Comp.
SQL Over
Sockets
Audit Data
DB
Server
An Example
Threat 1: A malicious user can view or tamper with
personal data en route from the Web server to the client
or from the client to the Web server
Threat 2: A malicious user can view or tamper with
personal data en route from the Web server to the
application component or from the component to the
Web server
An Example
Threat 3: A malicious user can access or tamper
with the personal data directly in the database
Threat 4: A malicious user can view LDAP
Authentication packets and learn how to reply to
them so that he can act “on behalf of” the user
An Example
Threat 5: A malicious user can deface or redirect
the Web server by changing one or more Web
pages
Threat 6: An attacker can deny access to the
database server by flooding it with TCP/IP
packets
An Example
Threat 7: An attacker can delete or modify the
audit logs
Threat 8: An attacker can place his own Web
server on the network after killing the original
server with a distributed DoS attack.
OWASP.org
Open Web Application Security Project
Top-Ten Web Security Vulnerabilities
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#10: Web/App Server
Misconfiguration
Tension between “work out of the
box” and “use only what you need”
Developers ≠ web masters
Examples
Unpatched security flaws
Misconfigurations that allow
directory traversal
Administrative services accessible
Default accounts/passwords
Countermeasures
Create and use hardening guides
Turn off all unused services
Set up and audit roles,
permissions, and accounts
Set up logging and alerts
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#9 Denial-of-Service
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#8: Poor Cryptography
Insecure storage of credit cards, passwords, etc.
Poor choice of algorithm (or invent your own)
Poor randomness
Session IDs
Tokens
Cookies
Improper storage in memory
Countermeasures
Store only what you must
Store a hash instead of the full value
Use only vetted, public cryptography
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#7: Error Handling
Examples: stack traces, DB dumps
Helps attacker know how to target the app
Inconsistencies can be revealing too
“File not found” vs. “Access denied”
Fail-open errors
Need to give enough info to user w/o giving
too much info to attacker
Countermeasures
Code review
Modify default error pages (404, 401, etc.)
Error messages example
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#6: Command Injection
Allows attacker to relay malicious code in form
variables or URL
System commands
SQL
Interpreted code (Perl, Python, etc.)
Many apps use calls to external programs
sendmail
Countermeasures
Taint all input
Avoid system calls (use libraries instead)
Run with limited privileges
Injection in ASP
Login:
Select * from users where username = ‘” +
username + “’ and password = ‘” + password +
“’”;
Goal: gain information and administrator access
Methodology: inject SQL statement in the
‘username’ and ‘password’ fields
Collect information
Select * from users where username = ‘” + username + “’
and password = ‘” + password + “’”;
1.
Get database table
Username: ' having 1=1-[Microsoft][ODBC SQL Server Driver][SQL
Server]Column 'users.id' is invalid …
2.
Get columns
Username: ' group by users.id having 1=1-[Microsoft][ODBC SQL Server Driver][SQL
Server]Column 'users.username' is invalid …
3.
Get types
Username: ' union select sum(username) from users-[Microsoft][ODBC SQL Server Driver][SQL Server]The
sum or average aggregate operation cannot take a
varchar data type as an argument.
Gain access
Select * from users where username = ‘” + username + “’ and
password = ‘” + password + “’”;
4.
Get version info. Of SQL server and OS
Username: ' union select @@version,1,1,1-Syntax error converting the nvarchar value
'Microsoft SQL Server 2000 - 8.00.194 (Intel X86) …
Edition on Windows NT 5.0 (Build 2195: Service Pack
2) ' …
5.
Get usernames
Username: ' union select min(username),1,1,1 from
users where username > 'a'-Syntax error converting the varchar value 'admin'
to a column of data type int.
6.
Get password
Username: ' union select password,1,1,1 from users
where username = 'admin'-Syntax error converting the varchar value
'r00tr0x!' to a column of data type int.
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#5: Buffer Overflows
Mostly affects web/app servers
Can affect apps/libraries too
Goal: crash the target app and get a
shell
Buffer overflow example
echo “vrfy `perl –e ‘print “a” x 1000’`”
|nc www.targetsystem.com 25
Replace all those “a”s with something like this…
char shellcode[] =
“\xeb\xlf\x5e\x89\x76\x08…”
Countermeasures
Keep up with bug reports/patches
Code reviews
Run with limited privileges
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#4: Cross-Site Scripting (XSS)
Attacker uses trusted
application/company to reflect malicious
code to end-user
Attacker can “hide” the malicious code
Unicode encoding
2 types of attacks
Stored
Reflected
Wide-spread problem!
Countermeasures
input validation
Positive
Negative: “< > ( ) # &”
Don’t forget these: “&lt &gt &#40 &#41
&#35 &#38”
User/customer education
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#3: Broken Account and Session
Management
Weak authentication
Password-only
Easily guessable usernames (admin, etc.)
Unencrypted secrets are sniffable
How to break in
Guess/reset password
Have app email you new password
Sniff or crack password
Backend authentication
How are database passwords stored?
Trust relationships between hosts (IP
address can be spoofed, etc.)
Countermeasures
Strong passwords
Remove default user names
Protect sensitive files
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#2: Broken Access Control
Usually inconsistently defined/applied
Examples
Forced browsing past access control checks
Path traversal
File permissions – may allow access to
config/password files
Client-side caching
Countermeasures
Use non-programmatic controls
Verify access control via central container
Code reviews
Top-Ten Web Security
Vulnerabilities
1
2
3
4
5
6
7
8
9
10
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting (XSS) Flaws
Buffer Overflows
Injection Flaws
Improper Error Handling
Insecure Storage
Denial of Service
Insecure Configuration Management
#1: Unvalidated Parameters
Attacker can easily change any part of the HTTP request
before submitting
URL
Cookies
Form fields
Hidden fields
Headers
Encoding is not encrypting
Toasted Spam: http://www.toastedspam.com/decode64
Input must be validated on the server (not just the client).
CoolCarts: http://www.extremelasers.com
Countermeasures
Tainting (Perl)
Code reviews (check variable against list of allowed values,
not vice-versa)
Application firewalls
CodeSeeker: http://www.owasp.org/codeseeker/
Real-time auditing: http://www.covelight.com
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
Security Techniques Authentication
Authentication – The process of verifying a claimed
identity
User Authentication
The process of determining that a user is who he/she claims to
be
Usually happens only once per session
May need to re-authenticate during a session e.g. before a
significant monetary action
Entity Authentication
The process of determining if an entity is who it claims to be
Usually takes place with every request
Authentication
User Authentication
Basic authentication – Clear Text
Digest authentication
Forms-based authentication
<%
Dim strUsername, strPwd
strUsername = Request.Form(“Username”)
strPwd = Request.Form(“Pwd”)
%>
Passport authentication - SSO
Windows authentication
NTLM authentication
Kerberos authentication
X.509 certificate authentication
Authentication
Entity Authentication
Cookie based
Infrastructure Authentication
IPSec
X.509 certificate authentication
Authentication
Cookies
Persistent and Secure
Persistent and Non-secure
Non-persistent and Secure
Non-persistent and Non-secure
Authentication
Managing User Sessions
Session tokens
Cryptographic algorithms
All session tokens should be user unique, non-predictable,
and resistant to reverse engineering
Use a trusted random number generator
Map session tokens in some way to a specific HTTP client
instance to prevent hijacking and replay attacks
Do not base a session token algorithm on or use as
variables any user personal information
Authentication
Expire session tokens on the HTTP server when the session ends
Regenerate session tokens while the session is active
Build methods to detect session forging/brute-forcing and/or lockout
Re-authenticate users before significant actions
Encrypt session tokens during transmission
Use page-specific tokens in conjunction with session-specific tokens
Overwrite session tokens on logout
Security Techniques –
Authorization and Access Control
Limits what users can do, which resources they have access to, and
what functions they are allowed to perform on the data.
Authorization
The act of checking to see if a user has the proper permission to access
a particular file or perform a particular action
Access Control
The more general way of controlling access to web resources, including
restrictions based on things like the time of day, the IP address or
domain of the client browser, the type of encryption the HTTP client can
support, number of times the user has authenticated that day, etc.
Any access control mechanism depends on effective and forge-resistant
authentication controls for authorization
Access Control and Authorization
Access Control
Discretionary Access Control
Restricts access to information based on the identity
Decentralized model
Mandatory Access Control
Assigning sensitivity labels on information and comparing this
level of sensitivity at which a user operates
For extremely secure systems
Role-based Access Control
Access decisions are based on an individual’s roles and
responsibilities within the organization or user base
Centralized administration
Scalable
Access Control and Authorization
In Windows Environment
Access Control Lists
Privileges
IP Restrictions
Server-Specific Permissions
Security Techniques
Tamper-Resistant and Privacy-Enhanced
Technologies
SSL / TLS
IPSec
DCOM and RPCs
Encrypting File System
Security Techniques
Protect Secrets – Don’t Store Secrets
If you don’t store the data, the attacker cannot gain access!
Encryption, Hashes, MACs, and Digital Signatures
Hide information from prying eyes.
Filtering
Inspect data as received and making a decision to accept or reject
Throttling
Limit the number of requests to your system
Quality of Service
Preferential treatment for specific types of traffic
Least Privilege
Always run with just enough privilege to get the job done
Security Techniques - Logging
Importance of logging
Provides key security information about a web application
and its associated process and integrated technologies
Makes individual users accountable for their actions
Often the only record of suspicious behavior – Base of
IDS
Logging
What to log
In general, time of event, initiating process or owner of
process, detailed description of the event
Reading/writing/modifying/deleting data
Network communications at all points
All authentication/authorization events
All administrative functions, regardless of
Debugging information that can be enabled/disabled on
the fly
Logging
Best practices for log management
Collect and consolidate logs on a separate dedicated logging host
Encrypt network connections and log data contents to protect
confidentiality and integrity
Set log file attributes so that only new information can be written
(older records cannot be rewritten or deleted)
Copy logs at regular intervals, depending on size and volume
Verify regularly that logging is operational
Copy log files to permanent storage and include in backup strategy
Dispose of log files according to company record retention policy
Synchronize all logging components with a time server so that all
logging can be consolidated effectively without latency errors.
Some Common Threats
Access to or modification of confidential data
Read or modify e-mail-based communication
Flood service with too many connections
Attempt to guess password
Attacker spoof a server
Attacker posts HTML or scripts to your site
Your data packets can be replayed
Attacker gains physical access to hardware
Attacker modifies configuration data
Error message leak too much information
An attacker accesses or uses data cached by a previous user
Attacker shuts down your process
Attacker modifies configuration data
What to do next?
Here are a few tips for the beginning:
Data Validation
Privacy Considerations
Data Validation
One of the most important aspects of designing a secure web
application
Applies to input to and output from a web application
Validation strategies
Accept only known valid data
Accept only input that is known to be safe and expected
The best possible strategy, but not always feasible
Reject known bad data
Can limit exposure
Relies on the application knowing about specific malicious payloads
Sanitize all data
An effective second line of defense
May be hard and time-consuming to perform
Data Validation
All three data validation strategies must check
Data type
Syntax
Length
Never rely on client-side validation
Data validation must be done on the trusted server or under
the control of the application
Client-side data validation can always be bypassed
An attacker can watch the return value and modify it at will
Privacy Considerations
Warn users about the dangers of communal web
browsers
Pages may be retained in the browser cahce
Logging out and closing the browser to kill session cookies is
recommended
Temp files may remain
Proxy servers and other LAN users may intercept traffic
Design sites with the assumption that no part of a client
is secure and make no assumptions about integrity
Privacy Considerations
Display personal data when really needed
Set pages to pre-expire
Set the no-cache meta tags
Otherwise, mask personal data, displaying only a subset
Offer an enhanced privacy login option to the user
Keep sensitive data out of the browser history by using
POST for all form submissions
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.