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.

1. Web Application Security
21/03/2012

2. Softjourn Inc.
Web Application Security
Anatoliy Okhotnikov
Softjourn Inc.

3. Web Application Security

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.

8. Why this is important?

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

12. Mitigations

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

15. Designing Secure Web Applications

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

17. Designing: input validation strategies

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

19. Designing: authentication

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

23. Designing: sensitive data
 Secrets
 Sensitive per user data

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

27. Designing: exception management
 Do not leak
information to
the client
 Log detailed
error messages
 Catch
exceptions

28. Designing: auditing and logging
 Audit and log
access across
application tiers
 Consider identity
flow
 Log key events
 Secure log files
 Back up and
analyze log files
regularly

29. Building Secure Web Applications

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

36. Secure Web App: cryptography
 Use Platform-provided Cryptographic
Services
 Key Generation
 Key Storage
 Key Exchange
 Key Maintenance

37. Secure Web App: architecture & design
 Input validation
 Authentication
 Authorization
 Configuration Management
 Sensitive Data
 Session Management
 Cryptography
 Parameter Manipulation
 Exception Management
 Auditing & Logging

38. Securing Your Network, Web Server
and Database
 Securing your network
 Securing your web server
 Securing your database

39. Securing Your Network

40. Securing Your Network: routers
 Patch & Update
 Ingress & Egress Filtering / Screen Traffic
 Prevent TTL Expired Messages with Values of 1
or 0
 Do Not Receive or Forward Directed Broadcast
Traffic
 Disable Unused Interfaces
 Apply Strong Password Policies
 Use Static Routing
 Audit Web Facing Administration Interfaces
 Auditing and Logging / Intrusion Detection

41. Securing Your Network: firewalls
 Patch & Update
 Filters
 Packet filters
 Circuit-level filters
 Application filters
 Stateful inspection
 Custom application filters
 Logging & Auditing
 Perimeter Networks

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

46. Assessment: Injection

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.

48. Assessment: Cross-Site Scripting (XSS)

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.

50. Assessment: Broken Authentication and
Session Management

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?

52. Assessment: Insecure Direct Object
References

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.

54. Assessment: Cross-Site Request Forgery
(CSRF)

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.

56. Assessment: Security Misconfiguration

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?

58. Assessment: Insecure Cryptographic
Storage

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?

60. Assessment: Failure to Restrict URL
Access

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.

62. Assessment: Insufficient Transport Layer
Protection

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?

64. Assessment: Unvalidated Redirects and
Forwards

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.

66. Assessment: Additional Risks to Consider

67. Assessment: Additional Risks to Consider
 Clickjacking (UI redress attack)
 Concurrency flaws
 Denial of service
 Header injection
 Information leakage and Improper error
handling
 Insufficient anti-automation
 Insufficient logging and accountability
 Lack of intrusion detection and response
 Malicious file execution

68. Links
• http://en.wikipedia.org/wiki/Web_application_s
ecurity
• http://cwe.mitre.org/top25/
• http://msdn.microsoft.com/en-
us/library/ff649874.aspx
• http://www.applicure.com/solutions/web-
application-security
• http://www.clusif.asso.fr/fr/production/ouvrage
s/pdf/CLUSIF-2010-Web-application-
security.pdf
• http://www.webappsec.org/
• http://code.google.com/p/owasptop10/
Copyright © 2000-2011 Softjourn, Inc. All rights reserved

69. Questions & discussion
“Anatoliy Okhotnikov”
<aokhotnikov@softjourn.com>
Copyright © 2000-2011 Softjourn, Inc. All rights reserved