Web Application Security

1
Web Application Security

• Presented by
• Joseph Seaman, CISSP, CISA, GSEC
• Jseaman_at_entint.com
• October 8, 2003

2
Agenda

• Top Ten Web Vulnerabilities
• Tools
• Resources

3
Know Your Enemy
It is said that if you know both the, enemy and
yourself, you will fight a hundred battles
without danger of defeat if you are ignorant of
the enemy but only know yourself, your chances of
winning and losing are equal if you know neither
the enemy nor yourself, you will certainly be
defeated in every battle. SUN TZU ON THE ART
OF WAR THE OLDEST MILITARY TREATISE IN THE
WORLD Chinese general, circa 500 B.C.
4
The Game is Afoot
5
Security is a Process

• Security goes beyond establishing a firewall and
  implementing SSL.
• Includes IDS, Policy, Standards, Awareness,
  Audit, Testing, Testing, and Testing.
• Do not assume someone else is taking care of it.
• Sweat the easy stuff!!!

6
Web Application Security cuts through many
different aspects of an organizations
information security infrastructure.
7
Top 10 List

• Unvalidated Parameters
• Broken Access Control
• Broken Account and Session Management
• Cross-site Scripting(XSS) Flaws
• Buffer Overflows
• Command Injection Flaws
• Error Handling Problems
• Insecure Use of Cryptography
• Remote Administration Flaws
• Web and Application Server Misconfiguration

8
1. Unvalidated Parameters

• Parameters should validate
• Data Type(string, Integer, real etc)
• Allowed character set
• Minimum and maximum length
• Whether null is allowed
• Whether the parameter is required or not
• Whether duplicates are allowed
• Numeric range
• Specific legal values(enumeration)
• Specific patterns( regular expressions)

9
2. Broken Access Control

• Specific Access control issues
• Insecure IDs
• Forced Browsing Past Access Control Checks
• Path Traversal
• File Permissions
• Client Side caching

10
3. Broken Account and Session Management

• Critical areas
• Password Change Controls
• Password Strength/Storage
• Protecting Credentials in Transit
• Session ID Protection
• Account Lists
• Browser Caching
• Trust Relationships
• Backend Authentication

11
Session ID Overview

• Session IDs are commonly stored in cookies and/or
  URLs, and hidden fields of web pages (or some
  combination)
• Session ID generated by WEB SERVER (IIS, etc.)
  when the user first hits the site or by WEB
  APPLICATION (ATG dynamo, Apache Tomcat, BEA
  Websphere, .jsp, .asp, perl, etc.) when the user
  logs in

12
Session IDs in Hidden Fields
ltFORM METHODPOST ACTION"/cgi-bin/bankofnorthernh
emispher.cgi"gt ltinput type"hidden"
name"sessionID" valueqwerty1234gt ltinput
type"hidden" name"useraccount"
value4456-563490gt ltinput type"submit"
name"Access Checking Account"gtlt/formgt
13
6 Common Problems

• Weak Algorithm Many web sites today are
  currently using linear algorithms based on easily
  predictable variables such as time or IP address.
  
• No Form of Account Lockout Can perform Session
  ID brute force attacks without a single complaint
  from the web server.  
• Short Key Space Even the most cryptographically
  strong algorithm still allows an active Session
  ID to be easily determined if the size of the
  strings key space is not sufficiently large.
•  

14
6 Common Problems

• Indefinite Expiration on Server allow an
  attacker unlimited time to guess a valid Session
  ID.  
• Transmitted in the Clear For those situations
  where SSL is not being used while the Session ID
  cookie is transmitted to and from the browser,
  the Session ID could be sniffed across a flat
  network taking the guess-work out.
• Insecure Retrieval By tricking the users
  browser into visiting another site, attacker can
  retrieve stored Session ID information and
  quickly exploit before the users sessions
  expire. This can be done a number of ways DNS
  poisoning, Cross-site Scripting, etc.

15
4. Cross-site Scripting(XSS) Flaws

• This technique is used pass various types of
  client-side scripting language through
  implemented security filters.
• The idea is to be able to achieve client-side
  execution of a client-side script.
• There are several techniques used to perform this
  attack.

16
5. Buffer Overflows
Many system put limits on how much data a
variable can store or a system can handle. Often
times if these limits are exceeded, the data will
still be used, but bypass certain security
considerations. URLs such as http//www.myweb.co
m/cgi?paramfilename Replaced with
http//www.myweb.com/cgi?paramlt5K_of_Datagt
17
6. Command Injection Flaws

• Includes system calls, shell commands and SQL
  calls(SQL injection)
• Limit use of shell commands
• Validate data against malicious content
• Treat supplied parameters as data
• Limit privileges

18
Command Injection Using Hex

• By URL hex encoding URL strings, it may be
  possible to circumvent filter security systems
  and IDS.
• http//www.myweb.com/cgi?file/etc/passwd
• Can become
• http//www.myweb.com/cgi?file/2F657463
• 2F706173737764

19
Double Hex Encoding

• Round 1 Decoding
• scripts/..255c../winnt
• becomes
• scripts/..5c../winnt
• (25 Character)
• Round 2 Decoding
• scripts/..5c../winnt
• becomes
• scripts/..\../winnt

Directory path traversal is now possible using
path obfuscation through Double Hex Encoding.
20
The Unicode Slash

• In unicode, c0af, is the equivilent to a
  slash (/).
• Therefore the common URL IIS exploit
• scripts/..c0af../winnt
• becomes
• scripts/../../winnt

Directory path traversal is now possible using
path obfuscation this time through Unicode.
21
7. Error Handling Problems

• Define policy
• Limit only what is necessary
• Invalid account
• Incorrect password

22
8. Insecure Use of Cryptography

• Common mistakes include
• Insecure storage of keys, certificates, and
  passwords
• Improper storage of secrets in memory
• Poor sources of randomness
• Poor choice of algorithm
• Failure to encrypt critical data
• Attempting to invent a new encryption algorithm
• Failure to include support for encryption key
  changes and other required maintenance procedures

23
9. Remote Administration Flaws

• Restrict access through front door
• Use VPN or SSL whenever possible
• Segment and Filter access
• Use strong authentication

24
10. Web and Application Server Misconfiguration

• Configure all security mechanisms
• Turn off all unused services
• Set up roles, permissions, and accounts
• Logging and alerts
• Monitor for latest vulnerabilities
• Patch, Patch, Patch
• Vulnerability Scanning

25
Dangerous HTML Tags

• All HTML is to be considered dangerous, but
  these tags are the most insidious.

• ltAPPLETgt
• ltBODYgt
• ltEMBEDgt
• ltFRAMEgt
• ltFRAMESETgt
• ltHTMLgt
• ltIFRAMEgt
• ltIMGgt
• ltLAYERgt
• ltILAYERgt
• ltMETAgt
• ltOBJECTgt
• ltSCRIPTgt
• ltSTYLEgt

26
What Can I Do As a User?

• Logout of all sessions when done
• Do not select the Remember me Option
• Protect your cookies! Desktop Security
• Ensure you use SSL when given choice of
  standard / secure login
• Patch your browser to be safe from some nasty
  Cross-site Scripting attacks
• Treat emails with Session ID info in URLs just
  as securely as username/passwords

27
What can I do as a Developer?

• Build and require SSL (or other encryption) into
  the web application so that the authentication
  token can not be easily sniffed in transit
  between browser and server
• Ensure that all cookies enable the "secure" field
• Provide a logout function that expires all
  cookies and other authentication tokens
• Re-authenticate the user before critical actions
  are performed (i.e. a purchase, money transfer,
  etc.)

28
What can I do as a Developer?

• Regenerate the Session ID after certain intervals
  (30, 15 min. ,etc.)
• Create booby-trapped Session IDs to detect
  brute forcing attempts
• When practical, limit successful sessions to
  specific IP addresses. Only works in intranet
  setting where ranges are predictable and finite.
• Auto-expire sessions after 15 minutes of
  inactivity
• Enforce a nonce on previous pages

29
Tools

• Visual Testing WebSleuthhttp//www.sandsprite.c
  om/Sleuth/
• WebProxy -http//www.atstake.com/webproxy/
• HTTPush - http//sourceforge.net/projects/httpush
• Achilles - http//www.mavensecurity.com/achilles
• MiniBrowser - aignes.com/download.htm

30
Resources

• Open Web Application Security Project (OWASP)
  http//www.owasp.org
• OWASP is an open source community project staffed
  entirely by volunteers from across the world. The
  project is developing software tools and
  knowledge based documentation that helps people
  secure web applications and web services.
• The OWASP Guide to Building Secure Web
  Applications and Web Services
• http//www.owasp.org/documentation/
• guide

31
Resources

• CGI SECURITY, http//www.cgisecurity.net
• Web Application Security Mailing List,
  http//online.securityfocus.com/archive/107
• MIT Publications http//pdos.lcs.mit.edu/cookies/p
  ubs.html
• Dos and Don'ts of Client Authentication on the
  Web

32
Security Audit Software
33
Questions?