OWASP Top 10

.OWASP Top 10 Security Flaws

OWASP Top 10 Security Flaws

The Open Web Application Security Project (OWASP) is technology agnostic non-profit organization dedicated to web application security. OWASP is registered in Belgium with 200 chapters in over 100 countries. OWASP has free and open security tools and books on application security development and testing. This article review the "Top 10" project, but other OWASP projects include:

  1. OWASP Software Assurance Maturity Model
  2. OWASP Development Guide
  3. OWASP Testing Guide
  4. OWASP Code Review Guide
  5. OWASP Application Security Verification Standard (ASVS)
  6. OWASP XML Security Gateway (XSG) Evaluation Criteria Project
  7. OWASP ZAP Project
  8. Webgoat
.OWASP Top 10 Security Flaws

OWASP Top 10 Project

The goal of the Top 10 project is to raise awareness of web application security by identifying some of the most critical risks. The top 10 security risks were determined by a consensus of security experts from around the world. The Top 10 is recommended as a good starting point, but there are hundreds of issues that can affect the security of a web application. The Top 10 is periodically updated to keep up with the advances of attackers and changing technology. This article reviews the OWASP Top 10 - 2013: The Ten Most Critical Web Application Security Risks publication.

.OWASP Top 10 List

OWASP Top 10 Project

The OWASP Top 10 Web Application Security Risks for 2013 are:

  1. Injection - Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

  2. Broken Authentication and Session Management - Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

  3. Cross-Site Scripting (XSS) - XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

  4. Insecure Direct Object References - 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.

  5. SecurityMisconfiguration - Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

  6. Sensitive Data Exposure - Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

  7. Missing Function Level Access Control - Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

  8. Cross-Site Request Forgery (CSRF) - A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the
    victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

  9. Using Components with Known Vulnerabilities - Components, such as libraries, frameworks, and other software modules, almost always run with
    full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

  10. Unvalidated Redirects and Forwards - 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.

Injection

SQL injection is the number one security threat because it is easy to learn and can completely compromise the database. Programs exist which will run various SQL injection exploits against a website. These free programs are available from the Internet and only require you to paste in a URL. The program then runs various SQL injection exploits against the web site in an attempt to extract data or harm the database.

An SQL injection exploit is performed using a normal HTTP request. The malicious user simply manipulates the query in the request to alter the action performed by the server. SQL injection possibilities are so numerous that they are classified by their methods, or their intent (Blind Injection, Union Query, Piggy-Backed Queries, Inference, Alternate Encodings, Illegal Queries, Second Order SQL Injection, ...).

All SQL injection is due to dynamic SQL queries. Parameterized queries work in a manner that separates out the data from the SQL, thus defeating any attempts to inject malicious code into an SQL statement. LINQ to Entities, and all ORM's, transparently utilizes parameterized queries at a low level, making them free from the threat of SQL injection.

When Dynamic SQL concatenates user input to SQL statements, then malicious users may be able to pass SQL as part of the input data in a way that alters the original intent of the SQL. Such as return unauthorized data, drop tables, and so on. Below is an example of a potentially unsafe dynamic SQL statement which could be suseptible to SQL injection.

1
           string SQL = "select * from customers where name ='" + tbxCustomerName + "';"


Dynamic SQL Suseptible to Injection

The "trusted" data comes from the program code, while the "untrusted" data is the user input. User input can be text entered in a form field, such as a textbox, or a modified query string. In the code above, the untrusted data is entered from a textbox. If the user enters:

' or '1'='1' --

it could return every row in the table because '1'='1' evaluates to true and -- (or the appropriate comment for the SQL version) comment blocks the rest of the SQL command.

Likewise, if the user enters:

A'; drop table customerOrders; SELECT * FROM customerInfo WHERE '1' = '1

it could drop the customer Orders table and return the data for every row in the customer Info table.


If dynamic SQL queries are required, the following is a list of ways to help protect against SQL injection:

  1. Whitelist Untrusted Data - Check the input data adheres to expected patterns. Use regular expressions to verify the data conforms to the expected pattern. Some frameworks will automatically Blacklist input data and throw an exception if the input field contains certain characters. However this capability varies among frameworks, and framework versions, and is also configurable at various levels. Don't assume the framework Blacklist functionality is going to protect you unless you have tested it at the page level.

  2. Used Parameterized Commands - Dynamic SQL statements can be created with parameterized commands (such as String.Format) that allows the data to be kept separate from the SQL. The parameters can be defined as variables which are strongly type (if using a strongly-typed language). If text is passed in instead of an integer, the strongly-typed language will detect an error, and this detection can be used to prevent the text from being used in the SQL statement.

  3. Properly Set Database User Permissions - Give the web user the "least permissions" they need to run the application. I have seen developers use their database account (which contain full database permissions) in the database connection string. Sometimes this is done for convenience during early development, but then for whatever reason it does not get changed before going to production. It is best to set up a Web User database account, with the least needed permissions, at the beginning of development, and use that account in the database connection string.

  4. Fine Tune Database Permissions - Use "Laced Permissions" in the application. Database permissions would be adjusted at various points in the application to only provide the permissions needed to access the data required for a particular point in the application. Excessive database rights opens the door for SQL injection.

Note: Besides SQL, other queryable systems, such as LDAP (Lightweight Directory Access Protocol), are also susceptible to injection exploits.

.LulzSec
Error | ASP.NET Developer

Error

Error message

  • Warning: Cannot modify header information - headers already sent by (output started at /srv/disk9/1218369/www/kcshadow.net/aspnet/includes/common.inc:2748) in drupal_send_headers() (line 1232 of /srv/disk9/1218369/www/kcshadow.net/aspnet/includes/bootstrap.inc).
  • PDOException: SQLSTATE[42000]: Syntax error or access violation: 1142 INSERT command denied to user '1218369_b2cf'@'185.176.40.58' for table 'watchdog': INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 0 [:db_insert_placeholder_1] => cron [:db_insert_placeholder_2] => Attempting to re-run cron while it is already running. [:db_insert_placeholder_3] => a:0:{} [:db_insert_placeholder_4] => 4 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://www.kcshadow.net/aspnet/?q=owasp10 [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => 54.162.171.242 [:db_insert_placeholder_9] => 1534727997 ) in dblog_watchdog() (line 160 of /srv/disk9/1218369/www/kcshadow.net/aspnet/modules/dblog/dblog.module).
The website encountered an unexpected error. Please try again later.