Sumeru Cyber Security
  • Sumeru Cyber Security
  • Workarounds for prevalent vulnerabilities
    • Version Disclosure
    • Host Header Attack
    • HttpOnly and Secure Flag
    • Security Headers
    • Clickjacking
    • Weak Password
    • Username Enumeration
    • jQuery Outdated
    • Cross-Origin Resource Sharing
    • AWS S3 Bucket Misconfiguration
    • Directory Listing
    • Laravel Debug Enabled
    • Autocomplete and Remember Password Enabled
    • Brute Force Attack
    • Cross Site Request Forgery
    • SQL Injection
    • PhpMyAdmin page Available Publicly
    • Implementation of BASIC Authentication
    • Cache Browsing
    • Insecure Direct Object Reference
    • Active mixed content over https
    • Improper forgot password implementation
    • ASP.NET Debug Enabled
    • Sensitive Data Sent in GET Request
    • Weak CAPTCHA Implementation
    • Csv Injection
    • Cross Site Scripting
    • Web Server Robot.txt Information Disclosure
    • SSL Related Issues
    • Local File Inclusion
    • Weak CAPTCHA Implementation
    • Automated Form Submission
    • Php.ini File Available Publicly
    • ITLP
    • Internal Path Disclosure
    • Insecure Direct Object Reference
    • Access Token Not Expiring After Logout
  • OWASP A09-Security Logging and Monitoring Failures
  • OWASP API09-Improper Inventory Management v1.0
Powered by GitBook
On this page
  • Introduction
  • How to test
  • CASE 1
  • SQL INJECTION IN LOGIN PAGE:
  • CASE 2
  • How to Fix
  • PHP
  • JSP
  • References

Was this helpful?

  1. Workarounds for prevalent vulnerabilities

SQL Injection

PreviousCross Site Request ForgeryNextPhpMyAdmin page Available Publicly

Last updated 5 years ago

Was this helpful?

Introduction

SQL Injection (SQLi) refers to an injection attack wherein an attacker can execute malicious SQL statements (malicious payload) that control a web application’s database server.

This could result in loss of integrity as an attacker will be able to add, modify and delete records in database

SQL Injection can provide an attacker with unauthorized access to sensitive data including, customer data, personally identifiable information (PII), trade secrets, intellectual property and other sensitive information. Also allows an attacker to bypass a web application’s authentication and authorization mechanisms and retrieve the contents of an entire database.

How to test

CASE 1

SQL INJECTION IN LOGIN PAGE:

To test the SQL injection in the login we have to inject the malicious payloads in the username and in the password field.

First we want to assume the query which is being used in the application For Eg: Since it is the login form by assuming the select query as “SELECT username,password from users where username=’ ’ AND password = ‘ ’”

Since we don’t know values which is present in the above query for the username and password. We want to make the SELECT statement as TRUE by injecting the malicious payloads.

In the above screenshots we have show the sample login page to show the demo and in the username and the password field we have used the payload to login as ‘ or 1=1# which describes “SELECT username,password from users where username=’’ or 1=1# ’ AND password = ‘ ‘ or 1=1#’ ” this Query.

The payload which we have given in the above query describes ‘ is to end the quotes then it will look up to the OR 1=1 # or we can use -- is to comment the ‘ since the OR condition is true.

We successfully logged in to the Home page as shown in the below screenshot.

CASE 2

If there is a page with search field to show the data’s what we are searching in the search field as shown in the below screenshot

Above Screenshot describes for eg: if we search the data as ”test” it is fetching this data from the database and shown in this page. In this case SQL Injection is possible.

How to Fix

A prepared statement is a feature used to execute the same (or similar) SQL statements repeatedly with high efficiency.

Compared to executing SQL statements directly, prepared statements have three main advantages:

  • Prepared statements reduce parsing time as the preparation on the query is done only once. (although the statement is executed multiple times)

  • Bound parameters minimize bandwidth to the server as you need send only the parameters each time, and not the whole query.

  • Prepared statements are very useful against SQL injections, because parameter values, which are transmitted later using a different protocol, need not be correctly escaped. If the original statement template is not derived from external input, SQL injection cannot occur.

PHP

Sample code:

$sql = "SELECT * FROM Table_name WHERE colunmn_name =?";  
$stmt = $conn->prepare($sql);  
$stmt->bind_param("i", $id); 
$stmt->store_result(); 
$stmt->execute(); 

JSP

Sample code:

String sql = "SELECT * FROM users WHERE email = ? and password = ?"; 
PreparedStatement statement = connection.prepareStatement(sql); 
statement.setString(1, email); 
statement.setString(2, password); 
ResultSet result = statement.executeQuery(); 

References

https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
https://www.w3schools.com/php/php_mysql_prepared_statements.asp
https://www.codejava.net/coding/how-to-code-login-and-logout-with-java-servlet-jsp-and-mysql