This document provides an overview of web application security. It discusses why security is important for web applications and outlines common security threats. It then covers topics like designing secure applications, building them securely, and assessing security. Design considerations include input validation, authentication, authorization, and session management. Building securely involves role-based access control, exception handling, and cryptography. Assessment involves testing for vulnerabilities like injection flaws and broken authentication.
4. 3/21/12
Agenda
● Why this is important? What to do?
● Security threats & Mitigations
● Designing Secure Web Applications
● Building Secure Web Applications
● Securing Your Network, Web Server and
Database
● Assessing Your Security
5. Why this is important?
Web applications allow visitors
access to the most critical
resources of a web site, the web
server and the database server
Deface a web site
Loss of trust with customers
and/or visitors
Damaged brand reputation
Lost sales revenue
Your site labeled as a malicious
Loss of search engine rankings
6. Why this is important? (more)
Insert spam links directing visitors to another site
Insert malicious code that installs itself onto a
visitor’s computer
Insert malicious code that steals session IDs
(cookies)
Steal visitor information and browsing habits
Steal account information
Steal information stored in the database
Access restricted content
And much more...
7. What to do?
Build a hack-resilient application
reduces the likelihood of a successful attack
and mitigates the extent of damage if an
attack occurs. It resides on a secure host
(server) in a secure network and is developed
using secure design and development
guidelines.
9. Security threats
SQL injection
OS Command injection
Classic buffer overflow
Cross-site scripting (XSS)
Missing authentication
and/or authorization
Direct site attacks
more...
10. Security threats (more)
Use of Hard-coded Credentials
Missing Encryption of Sensitive Data
Unrestricted Upload of File with Dangerous Type
Reliance on Untrusted Inputs in a Security
Decision
Execution with Unnecessary Privileges
Cross-Site Request Forgery (CSRF)
Improper Limitation of a Pathname to a
Restricted Directory ('Path Traversal')
Download of Code Without Integrity Check
even more...
11. Security threats (even more)
Incorrect Authorization
Inclusion of Functionality from Untrusted Control Sphere
Incorrect Permission Assignment for Critical Resource
Use of Potentially Dangerous Function
Use of a Broken or Risky Cryptographic Algorithm
Incorrect Calculation of Buffer Size
Improper Restriction of Excessive Authentication
Attempts
URL Redirection to Untrusted Site ('Open Redirect')
Uncontrolled Format String
Integer Overflow or Wraparound
Use of a One-Way Hash without a Salt
13. Mitigations
Establish and maintain control over all of
your inputs and outputs
Lock down your environment
Assume that external components can be
subverted, and your code can be read by
anyone
Use industry-accepted security features
instead of inventing your own
more...
14. Mitigations (more)
Use libraries and frameworks that make it
easier to avoid introducing weaknesses
Integrate security into the entire software
development lifecycle
Use a broad mix of methods to
comprehensively find and prevent
weaknesses
Allow locked-down clients to interact with
your software
16. Designing Secure Web Applications
Design input validation strategies
Partition Web sites into open and restricted areas
Implement effective account management practices
Develop effective authentication and authorization
strategies
Protect sensitive data
Protect user sessions
Prevent parameter manipulation
Handle exceptions securely
Secure an application’s configuration management
features
List audit and logging considerations
18. Designing: input validation strategies
Assume ALL input is malicious
Centralize your approach
Do not rely on client-side validation
Be careful with canonicalization issues
Constrain, reject and sanitize your
input
Use common input handling practices
20. Designing: authentication
Separate public and restricted areas
Use account lockout policies for end-user
accounts
Support password expiration periods
Be able to disable accounts
Do not store passwords in user stores
Require strong password
Do not send password over the wire in
plaintext
Protect authentication cookies
21. Designing: authorization
Use multiple gatekeepers
Restrict user access to
system level resources
Consider authorization
granularity
22. Designing: configuration management
Secure your
administration interfaces
Secure your
configuration stores
Separate administration
privileges
Use least privileged
process and service
accounts
24. Designing: session management
Use SSL to protect
session authentication
cookies
Encrypt the contents of
the authentication
cookies
Limit session lifetime
Protect session state
from unauthorized
access
25. Designing: cryptography
Do not develop your own
cryptography
Keep unencrypted data
close to the algorithm
Use the correct
algorithm and correct
key size
Secure your encryption
keys
26. Designing: parameter manipulation
Encrypt sensitive
cookie state
Make sure that users
do not bypass your
checks
Validate all values sent
from the client
Do not trust HTTP
header information
30. Building Secure Web Applications
Role-based Security, URL
authorization
Code Access Security
Be aware of unauthorized access,
privilege elevation, code injection,
information disclosure, tampering
Log events
Data Access
Obfuscation
31. Secure Web App: class design
Restrict Class &
Member Visibility
Seal Non-Base
Classes
Restrict Which Users
Can Call Your Code
Expose Fields Using
Properties
32. Secure Web App: exceptions
Use Structured Exception
Handling
Do Not Log Sensitive Data
Do Not Reveal Sensitive
System or Application
Information
Consider Exception Filter
Issues
Consider an Exception
Management Framework
33. Secure Web App: file I/O
Avoid Untrusted Input for File Names
Do Not Trust Environment Variables
Validate Input File Names
Constrain File I/O Within Your
Applications' Context
34. Secure Web App: serialization
Do Not Serialize Sensitive Data
Validate Serialized Data Streams
Partial Trust Considerations
35. Secure Web App: threading
Do Not Cache the Results of Security
Checks
Consider Impersonation Tokens
Synchronize Static Class Constructors
Synchronize Dispose Methods
42. Securing Your Network: switches
Patches & Updates
Virtual Local Area Networks (VLANs)
Insecure Defaults
Services
Encryption
43. Securing Your Web Server
Be aware of profiling, denial of service,
unauthorized access, arbitrary code
execution, elevation of privileges,
viruses, worms and trojan horses
Patches & Updates. Services.
Protocols. Accounts. Files &
Directories. Shares. Ports. Auditing &
Logging. Sites & Virtual Directories.
Script Mappings. API Filters. Server
Certificates. Permissions. Error
Messages. Sample & test files.
44. Securing Your Database
Be aware of SQL injection, network eavesdropping,
unauthorized server access, password cracking
Patches & Upgrades. Disable unused server services
Restrict server to TCP/IP, harden TCP/IP stack
Secure DB accounts, delete or disable unused accounts,
enforce strong password policy, restrict remote logons,
disable anonymous
Verify permissions on files & directories, secure or
remove tools, utilities and SDKs
Restrict access to DB port
Log all failed logon attempts, actions, enable SQL logging
Run server using a least privileged account
Do not grant permission to the public role
Remove sample DBs, secure stored procedures
45. Assessing Your Security
Get organized. Establish
the process
Standardize how you
verify web application
security (ASVS)
Assemble tools suite
(OWASP Live CD Project)
Code review. CodeCrawler,
Orizon, O2
Testing/Penetration.
WebScarab
47. Assessment: Injection
Verify that all use of interpreters clearly
separates untrusted data from the
command query.
Check the code. Code analysis tools can
help. Penetration testing with exploits.
Automated dynamic scanning which
exercises the application.
49. Assessment: Cross-Site Scripting (XSS)
Ensure that all user supplied input sent back to
the browser is verified to be safe and properly
escaped before it is included in the output
page.
Both static and dynamic tools can find some
XSS problems automatically, but complete
coverage requires a combination of manual
code review and manual penetration testing.
Web 2.0 technologies, such as AJAX, make XSS
much more difficult to detect via automated
tools.
51. Assessment: Broken Authentication and
Session Management
Are credentials always protected when stored using
hashing or encryption?
Can credentials be guessed or overwritten through
weak account management functions?
Are session IDs exposed in the URL?
Are session IDs vulnerable to session fixation
attacks?
Do sessions IDs timeout and can users log out?
Are session IDs rotated after successful login?
Are passwords, session IDs, and other credentials
sent over TLS connections?
53. Assessment: Insecure Direct Object
References
Verify that all object references have
appropriate defenses. Code review/testing.
For direct references to restricted
resources, the application needs to verify
the user is authorized to access the exact
resource they have requested.
If the reference is an indirect reference,
the mapping to the direct reference must
be limited to values authorized for the
current user.
55. Assessment: Cross-Site Request Forgery
(CSRF)
Verify if each link and form contains an
unpredictable token for each user.
Check multistep transactions, as they are not
inherently immune.
Note that session cookies, source IP addresses,
and other information that is automatically sent
by the browser doesn't count since this
information is also included in forged requests.
OWASP's CSRF Tester tool can help generate
test cases to demonstrate the dangers of CSRF
flaws.
57. Assessment: Security Misconfiguration
Do you have a process for keeping all your software
up to date? This includes the OS, Web/App Server,
DBMS, applications and all code libraries.
Is everything unnecessary disabled, removed or not
installed (eg ports, services, pages, accounts,
privileges)?
Are default account passwords changed or disabled?
Is your error handling set up to prevent stack traces
and other overly informative error messages from
leaking?
Are the security settings in your development
frameworks and libraries understood and configured
properly?
59. Assessment: Insecure Cryptographic
Storage
Which data is sensitive enough to require
encryption?
Is it encrypted everywhere it is stored long
term, particularly in backups of this data?
Can the authorized users only access
decrypted copies of the data?
Is a strong standard encryption algorithm
used?
Is a strong key generated, protected from
unauthorized access and key change is
planned for?
61. Assessment: Failure to Restrict URL
Access
Verify every page.
Consider is the page supposed to be public or private.
Is authentication required to access a private page?
Is a private page supposed to be accessible to ANY
authenticated user? If not, is an authorization check
made to ensure the user has permission to access
that page?
Verify external security mechanisms are properly
configured for every page? If code level protection is
used, verify that it is in place for every required page.
Penetration testing can also verify whether proper
protection is in place.
63. Assessment: Insufficient Transport Layer
Protection
Is SSL used to protect all authentication
related traffic?
Is SSL used for all resources on all private
pages and services?
Are strong algorithms only supported?
Have all session cookies their 'secure' flag
set?
Is the server certificate legitimate and
properly configured for that server?
65. Assessment: Unvalidated Redirects and
Forwards
Review the code for all uses of redirect or forward. For
each use, identify if the target URL is included in any
parameter values. If so, verify the parameter(s) are
validated to contain only an allowed destination, or
element of a destination.
Spider the site to see if it generates any redirects (300-
307). Look at the parameters supplied prior to the
redirect to see if they appear to be a target URL or a
piece of such URL. If so, change the URL target and
observe whether the site redirects to the new target.
If code is unavailable, check all parameters to see if
they look like part of a redirect or forward URL
destination and those that do.