Docstoc

The Owasp Top 10 - PowerPoint

Document Sample
The Owasp Top 10 - PowerPoint Powered By Docstoc
					Web Application Security
  (and why it matters to YOU!)
            -Remix-

     By Mark Bristow and Doug Wilson
         Mark.bristow@gmail.com
       DougWilsonMoo@gmail.com


                                       1
Your presenters today are

   Doug Wilson
          Senior Application Engineer at SAIC

   Mark Bristow
          Information Assurance Engineer at SRA
           International




                                                   2
Why are we here?



                   3
A brief discussion on
   What is Web Application Security?
        and   why does it matter?

   A look at the top problems on the web today

   And what you can do to remediate them.

               So, what is web application security?


                                                       4
Web application security is . . .
An overall process that

      Starts in   the initial planning stages

      Continues through coding,      testing, and
       deployment

      Doesn‟tfinish until the lifecycle is
       completely finished
                                                     5
But why does this matter to me?

 Overcoming Denial

    No one would ever bother with my web site.

    We already have “security”
            We use open source
            We use “that” vendor
            We keep up on patches

    “So we have a firewall, an IDS, an IPS, and use SSL
     . . . we‟re covered . . . right?”

                                                           6
No, you are probably NOT ok . . .
   The web was designed as a trusted
    environment. It is NOT that anymore.

   Web applications are still “emerging
    technologies” for most organizations.

   The drive to stay competitive results in
    unrealistic expectations and unsafe practices.


                                                     7
Looking at Some Recent IT
nightmares
   VA and other government agencies
     Personally  Identifiable Information (PII) for 26.5
      million veterans
   TJ Maxx and credit card processing
     45 million   credit card numbers
   AOL and User Data
     19 million   queries from 650,000 subscribers
   PaineWebber logic bomb
     2000 servers,   over $3.1 million just to restore


                                                            8
Web App specific numbers
   Symantec ISTR Jan-Jun 2007 (from September 2007)

       “61 percent of all vulnerabilities disclosed were Web
        application vulnerabilities.”
       “users . . . can no longer place their trust in well known
        sites.”

   CIO Magazine interviews Jeremiah Grossman (5/07)

       Vulnerabilities in 80% of websites analyzed
       Remaining 20% are mostly static sites
       Most C-level execs they talk to think firewalls protect against web
        application attacks -- THIS IS NOT TRUE!!!

                                                                              9
The bottom line? -- Liability

   Liability is not only costly financially, it can
    damage intangibles beyond repair.

   Even if you can afford to lose money, how much
    is your reputation worth?

   Regardless of the who broke it, the liability lies
    with the people who create and maintain these
    systems and their management.

                                                         10
So, how can we fix this?




                           11
OWASP -- what is that?
Open Web Application Security Project
               www.owasp.org

   Top Ten
   “Guides”
      Building secure web apps and services

      Application testing

      Code review

   Code projects
   Local Chapters, meetings, and conferences

                                                12
OWASP Top 10 – err . . . Top 5?

   Cross   Site Scripting (XSS)

   Injection   Flaws

   Malicious   File Execution

   Insecure    Direct Object Reference

   Cross   Site Request Forgery (CSRF)

                                          13
    Cross Site Scripting (XSS)

   What is Cross Site Scripting?
        Occurs when an application takes user supplied data and sends it to
         a web browser without validating or encoding that content

        In English: Can be anywhere you echo user input

   Getting the user to execute arbitrary code in their web browser


   XSS is everywhere, if you don‟t find it, are you doing something wrong?



                                                                         14
Why is XSS so dangerous?

   Compromise victim computer
   Can steal user‟s authentication credentials
   Intranet Port scanning
   Stealing Sensitive Data
   Key/Mouse logging
   WebWorms


                                                  15
XSS Demo




           16
Injection Flaws

   Occurs when user supplied data is sent to an
    interpreter as part of a command or query

   Comes in many flavors: SQL, LDAP, XPath,
    XSLT, HTML, XML, OS command injection, and
    more




                                                   17
 Injection Flaws – SQL Injection
 So, most people here have probably heard of . . .
 SQL Injection
        Injecting code to modify the intent of a SQL query



    What can I do with SQL Injection?
            Break or bypass Authentication
            Has the potential to expose your database data to an
             attacker
            Attacker can potentially modify your database structure
             and data

Select * from users where uname =‘’ and pw=‘’OR ‘Z’=‘Z’
                                                                   18
SQL Injection Demo




                     19
Fixing Injection Flaws
   The top two flaws are based on Injection
   Most of these are easily solved by following a
    few simple concepts religiously, in the way that
    works for your environment.
   Don‟t trust ANYTHING that comes from the
    client. Ever.
    1. Validate and type all input as strictly as you can.
    2. Encode and control all output as strictly as you can.




                                                               20
Input Validation

   Client side -- doesn‟t really do anything for
    security, though it still has its uses

   Server side – The only place where your
    validation provides security

   Regex – Your new best friend


                                                    21
Mechanics of good Validation

   White listing – Pass only when content contains
    only known good input

   Black Listing – Fail when a known bad is
    detected

   Sanitization – “Clean” data before using it based
    on Black or White List


                                                      22
Sanitization Issues
   Lets sanitize the name field against script injection
       String name = request.getParameter( "name" );
       name.replaceALL(“script”, “”);
       out.println(name);


   Test cases
       Name = “<script>alert(„I pwnt j00‟);</script>”
       Result: <>alert(„I pwnt j00‟);</>
       Name = “<scrscriptipt>alert(„I pwnt j00‟);</scrscriptipt>”
       Result: <script>alert(„I pwnt j00‟);</script>


   Sometimes this is a necessary evil

                                                                     23
Output Encoding

   Output should be encoded to match the delivery
    medium
        If it will be HTML, HTML encode.
        Ex: < becomes &lt;



   HTML Entity encoding will stop 99% of XSS
    attacks


                                                 24
Implementing Input Validation
   We are going to implement a white list validation
    for the username field
   What charecters are allowed in usernames?
     A-Z upper    and lower case
     Integers

   What regular expression matches this criteria
     [a-zA-Z0-9]

   How would we implement it in PHP
     if   (preg_match('/[^a-zA-Z0-9]/', $username)){ *FAIL* }

                                                             25
Implementing Input Validation




                                26
Now, back to our top 10 . . .
         or 5 . . .



                                27
Malicious File Execution
   Occurs when developers use user input directly in file or
    stream functions, or improperly trust uploaded content

   Can lead to rootkit installs and server compromise

   Many sites allow you to upload images or documents.
    The demo site allows you to submit reports.

   If this report submission is unfiltered you may be able to
    upload code to the website


                                                             28
Malicious File Execution Demo




                                29
Insecure Direct Object Reference
   A direct object reference occurs when a developer
    exposes a reference to an internal implementation
    object, such as a file, directory, database record, or key,
    as a URL or form parameter.
   Resource authorization checks should be conducted
    when the resouce is requested

   Common Examples
       User ID on query string: showAccount.php?id=2345
       Session ID on query String:
        index.php?PHP_SESSID=51h3nrstvi0mm60k2j179iqtg6
       Directory Traversal


                                                              30
Directory Traversal Demo




                           31
Fixing Object Access Flaws

   Don‟t trust ANYTHING that comes from the
    client. Ever.
     Validate
             and type all input as strictly as you can.
     Encode and control all output as strictly as you can.


   Do you sense a trend here?

   Perform authorization checks every time a
    resource is requested

                                                              32
Cross Site Request Forgery (CSRF)
   When an attacker forces a victim‟s browser to submit a
    request the victim did not intend to submit
   Also known as a “One click attack”, session riding or
    XSRF
   Exploits pre-established trust relationship (session) to
    force authorization
   High remediation costs
   Malicious requests and legitimate requests are
    indistinguishable.
   Originally dates to 1998 but is just becoming well
    understood

                                                               33
CSRF DEMO


            34
Fixing CSRF
   CSRF is often labeled as “unfixable,” it‟s inherent in how
    the web works. But you can take steps to help.

   Problems and safeguards
       Data returned as javascript (Gmail) -- fixed by while(); loop
       Digg article -- fix: secret tokens (a.k.a. Nonces)
       Amazon One-Click -- fix: Password re-entered

   Fixes work -- unless you combine with XSS. Then the
    rules change, and some standard fixes go out the
    window (like secret tokens)


                                                                        35
The rest of the OWASP Top 10
   Information Leakage
     Error   messages provide vital tools to an attacker
   Broken Session Management
   Insecure Cryptographic Storage
   Insecure Communications
     SSL   is a web attacker‟s best friend
   Failure to restrict URL access
     What happens   when I request an admin page directly
      without logging in first?

                                                            36
The AJAX question
   Does AJAX and other similar technologies make for
    “worse” application security? What about web services?

   Asynchronous applications and web services aren‟t
    innately more “insecure,” but greatly increase complexity
    and attack surface.

   Both Asynchronous and Web Service style applications
    have the potential to reintroduce a lot of old problems.

   Minimalist approach is best


                                                               37
Is the Sky Falling?

    The sky is NOT falling!
    All of the vulnerabilities mentioned here can be fixed
    Developer education and a robust software security
     program can help mitigate these issues
    Educate yourselves
    Educate your customers




                                                              38
How do I get started?
    LEARN! What threats are out there and how they
     apply to your organization?
    Classify what data is most important to your
     organization
    Identify all of your web applications and assign them
     criticalities based on business needs and data
     classification
    Perform vulnerability assessments to determine how
     big the problem is
    “Bake security in” to your SDLC


                                                             39
Resources
               Sites
                  http://www.owasp.org
                  http://www.webappsec.org/
                  http://ha.ckers.org
                  http://www.sans-ssi.org/
               Books
                  How to Break Web Software
                  Hacking Exposed : Web Applications
                  XSS ATTACKS
               Training
                  Certified Ethical Hacker (CEH)
                  Foundstone Ultimate Web Hacking
                  SANS Training
                     Securing Critical Web Applications and Web
                       Services (Aspect Security)
                     Writing Secure Web Applications: Developer
                       Training

                                                                   40
Questions?



stop by onelittlewindow.org
                         41

				
DOCUMENT INFO