- Jaimin Gohel

OWASP Top 10

A1- Injection Explained

About Speaker

  • InfoSec Enthusiast
  • Speaker
    • Null Ahmedabad
    • Mozilla Gujarat

What is OWASP?

The Open Web Application Security Project (OWASP) is a not-for-profit group that helps organizations develop, purchase, and maintain software application that can be trusted.

  • OWASP Top 10 Application Security Risks

  • Zap proxy

  • Mutillidae

The Top 10 (2017)

  • A1 - Injection
  • A2 - Broken Authentication
  • A3 - Sensitive Data Exposure
  • A4 - XML External Entities (XXE)
  • A5 - Broken Access Control
  • A6 - Security Misconfiguration
  • A7 - Cross-Site Scripting (XSS)
  • A8 - Insecure Deserialization
  • A9 - Using Components with Known Vulnerabilities
  • A10 - Insufficient Logging & Monitoring

What is injection?

  • When untrusted data is taken from user input and applied to some kind of query or interpreter in a way that assumes what the data will look alike.
  • An attacker enters data that does not fit the expected input but malforms in some way to have unintended consequences such as error leakage, damage or exposure of data.
  • An attacker can bypass any client side controls tha might be intended to stop this.
  • Usually related to SQL but can also apply to XPATH or Operating system calls or anything that builds a query from user input.

Types of injection

  • SQL Injection
  • XPath Injection
  • Code Injection
  • OS command injection

How common is it?

  • It is not the most common but it is the most serious vulnerability found in web applications.
  • If the site is susceptible it is usually quite easy to take adavantage of
    • eg. SQLMAP
  • It is usually easy to find out if a site is susceptible
    • Eg. syntax errors

A1 - Injection

Injection flaws, such as SQL, NoSQL, 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.

<?php 

mysql_query(“select * from users where name = ‘“.$_POST[‘name’].”’ AND 
password = ‘“.$_POST[‘password’].”’) ?>

name = ‘ or 1=1 – ← there is a space after the SQL comment

SQLi: SELECT * from users where name = '' or 1=1 -- AND password = '' ← always true

Secure Code

<?php

/* create a prepared statement */
if ($stmt = $mysqli->prepare("SELECT * from users where name=? AND password=?")) {

    /* bind parameters for markers */
    $stmt->bind_param("ss", $name,$password);

    /* execute query */
    $stmt->execute();

    /* bind result variables */
    $stmt->bind_result($details);

    /* fetch value */
    $stmt->fetch();

    /* close statement */
    $stmt->close();
}

DEMO

Remediation

  • Parameterized queries allow the framework to escape user input
  • Prepared statements are very useful against SQL injections, because parameter values, which are transmitted later using a different protocol, need not be correctly escaped.
  • Stored Procedures allow you to restrict what the application can do on the DB
    • Eg. like not permit select * from users
  • Input validation should be applied, server side to ALL user input in as restrictive way as possible
  • Do not only rely on input validation.

How Prepared statements prevent SQLi?

How Prepared statements prevent SQLi?

Resources and credits

  • https://www.owasp.org/index.php/Top_10-2017_A1-Injection
  • https://www.acunetix.com/blog/articles/injection-attacks/
  • http://javabypatel.blogspot.in/2015/09/how-prepared-statement-in-java-prevents-sql-injection.html

Questions?

Thank you.

Made with Slides.com