Wednesday, April 11, 2018

OWASP Top 10 Vulnerabilitie


1. SQL Injection Attacks

A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data Insert/ Update/ Delete

    
  Defenses:
      1: Use of Prepared Statements (with Parameterized Queries)
      2: Use of Stored Procedures
      3: White List Input Validation
      4: Escaping All User Supplied Input

2. Broken Authentication & Session Management
  Authentication is a critical part of any application, even solid authentication
  mechanisms can be undermined by flawed credential management functions, including
  password policy, password change, forgot my password, remember my password, account
  update, and other related functions.

  Web applications must establish sessions to keep track of the stream of requests
  from each user. HTTP does not provide this capability, so web applications must
  create it themselves. If session identifiers are not properly protected,
  an attacker can hijack an active session and assume the identity of a user.

  Defenses:
    1. Password Strength
    2. Password Use
    3. Password Change Controls
    4. Password Storage
    5. Protecting Credentials in Transit
    6. Session ID Protection

3. Cross-Site Scripting (XSS) Attacks
  Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious
  scripts are injected into trusted web sites generally in the form of a browser
  side script, to a different end user.The end user’s browser has no way to know
  that the script should not be trusted, and will execute the script. Because it
  thinks the script came from a trusted source, the malicious script can access
  any cookies, session tokens, or other sensitive information retained by the
  browser and used with that site.

  Defense:
    1.Never accept actual JavaScript code from an untrusted source and then run it
    2. HTML Escape Before Inserting Untrusted Data into HTML Element Content
    3. JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
    4. CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML
       Style Property Values
    5. URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
    6. Use HTTPOnly cookie flag

4. Insecure Direct Object References
  Insecure Direct Object References occur when an application provides direct access
  to objects based on user-supplied input. As a result of this vulnerability attackers
  can bypass authorization and access resources in the system directly, for example
  database records or files.

  Defense:
    1. Use per user or session indirect object references
    2. Check access

5.Security Misconfiguration
  Security Misconfiguration arises when Security settings are defined, implemented,
  and maintained as defaults. Good security requires a secure configuration defined
  and deployed for the application, web server, database server, and platform. It is
  equally important to have the software up to date.


  1. If Directory listing is not disabled on the server
  2. App server configuration allows stack traces to be returned to users
  3. App servers usually come with sample apps that are not well secured. If not
     removed from production server would result in compromising your server

6.Sensitive Data Exposure
  Sensitive data exposure vulnerabilities can occur when an application does not
  adequately protect sensitive information from being disclosed to attackers.

  Defense
    1. Encrypt the data and define accessibility
    2. Use SSL or TSL to ensure transport layer security
    3. Disable caching for pages that contain sensitive data.

Scenario #1: An application encrypts credit card numbers in a database using automatic
             database encryption. However, this means it also decrypts this data
             automatically when retrieved, allowing an SQL injection flaw to retrieve
             credit card numbers in clear text. The system should have encrypted the credit card
             numbers using a public key, and only allowed back-end applications to
             decrypt them with the private key.
Scenario #2: A site simply doesn’t use SSL for all authenticated pages. Attacker simply
             monitors network traffic (like an open wireless network), and steals the user’s
             session cookie. Attacker then replays this cookie and hijacks the user’s session,
             accessing the user’s private data.
Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file
             upload flaw allows an attacker to retrieve the password file. All of the unsalted
            hashes can be exposed with a rainbow table of pre-calculated hashes.

7. Missing Function Level Access Control
  Most of the web applications verify function level access rights before making
  that functionality accessible to the user. However, if the same access control
  checks are not performed on the server, hackers are able to penetrate into the
  application without proper authorization.

  Defense: The best way to find out if an application has failed to properly restrict
           function level access is to verify every application function:

           1. Does the UI show navigation to unauthorized functions?
           2. Are server side authentication or authorization checks missing?
           3. Are server side checks done that solely rely on information provided by the attacker?

8. Cross Site Request Forgery Attacks
  A CSRF attack forces an authenticated user (victim) to send a forged HTTP request,
  including session cookie, which allows the attacker to force the victim's browser
  to generate request such that the vulnerable app perceives as legitimate requests
  from the victim

  Defense
    1. CSRF can be avoided by using unique token
    2. CAPTCHA can be used to revalidate user.
    3. Only except Post request
for the execution of business logic
   

9. Using Components with Known Vulnerabilities Components
  When known vulnerabilities in the code exist, components, such as libraries and
  frameworks delivered from the open source community, shouldn’t be used

  Defense:
    1. Identify all components and the versions that are being used in the webapps
    2. Keep all the components such as public databases, project mailing lists etc. up to date.
    3. Add security wrappers around components that are vulnerable in nature

10. Unvalidated Redirects and Forwards
  Web applications on the internet frequently redirect and forward users to other
  pages or  external websites. Without validating the credibility hackers can redirect
  victims to phishing or malware sites, or use forwards to access unauthorized pages.

  Defense:
    1. Simply avoid using redirects and forwards.
    2. If used, don’t involve user parameters in calculating the destination. This can usually be done.
    3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.



Ref: https://www.owasp.org

No comments:

Post a Comment

AWS Services

      1.         Identity Access Management (IAM): Used to control Identity (who) Access (what AWS resources).                   1....