SQL Injection

SQL injection, also known as SQLI, is a common attack that uses malicious SQL code for back-end database manipulation to access information that was not intended to be displayed. This information may include any number of items, including sensitive company data, user lists or private customer details.

Actions a successful attack may take on a compromised target include:

• Bypassing authentication
• Stealing data
• Modifying or corrupting data
• Deleting data
• Running arbitrary code
• Gaining root access to the system itself

Types of SQL Injection

• Unsanitized Input  -  Unsanitized input is a common type of SQLi attack in which the attacker provides user input that isn’t properly sanitized for characters that should be escaped, and/or the input isn’t validated to be the type that is correct/expected.  Let's take an example of  authentication screen where we want to login to application , we have username & password as input on screen, which we are going to validate on back-end.
   
  Select ID from Users where username=’chpcloud’ and password=’P@$$w0rd’
  
  
  Often, the webserver will then see what is returned by the database server and if it is a number. In our case, the webserver would receive back a 1 and let the user past the login page. 
  Now as the input are not malicious so query will act as per expectation but whatLet's take another case where have unsanitized data
  
  
  Select ID from Users where username=’chpcloud’ and password=’x’ or 1=1
  
  This will work for us, because while x is not chpcloud’s password, the database server will then check the second condition. If x isn’t jsmith’s password, then does 1 equal 1? It does! The ID will be sent back to the application and the user will be successfully authenticated. This doesn’t have to be a 1=1 condition. Any two equal values will work, 2=2, 100=100 or even a=a.
  
  
• Union-based SQL injection—this technique takes advantage of the UNION SQL operator, which fuses multiple select statements generated by the database to get a single HTTP response. This response may contain data that can be leveraged by the attacke This combines two unrelated SELECT queries to retrieve data from different database tables.
  
  Highlighted is original query but some body might use union sql injection while passing the input using query.. the input is  http://www.netgear.com/Device/DeviceDetails?DeviceId=999 UNION SELECT user-name, password FROM USERS produces the following SQL query
  
  SELECT serialNumber, DeviceID
  FROM DeviceAccount 
  WHERE DeviceID= '999' UNION SELECT Username, Password FROM Users;
  
  
• Blind SQL Injection : 
  Blind SQL injection arises when an application is vulnerable to SQL injection, but its HTTP responses do not contain the results of the relevant SQL query or the details of any database errors.
  Consider an application that uses tracking cookies to gather analytics about usage. Requests to the application include a cookie header like this:
  Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4
  When a request containing a TrackingId cookie is processed, the application determines whether this is a known user using an SQL query like this:
  SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'
  This query is vulnerable to SQL injection, but the results from the query are not returned to the user. However, the application does behave differently depending on whether the query returns any data. If it returns data (because a recognized TrackingId was submitted), then a "Welcome back" message is displayed within the page.
• Time based Injection Time-based SQL Injection is an inferential SQL Injection technique that relies on sending an SQL query to the database which forces the database to wait for a specified amount of time (in seconds) before responding. The response time will indicate to the attacker whether the result of the query is TRUE or FALSE.

            SELECT
           CASE
          WHEN User= 'chpcloud'
          THEN pg_sleep(10)
          ELSE
         NULL END FROM users WHERE id = 999 ;

Prevention

• Don’t use dynamic SQL
  • Avoid placing user-provided input directly into SQL statements.
  • Use prepared statements and parameterized queries
  • Stored procedures are also usually safer than dynamic SQL but we will be not using until its not like must situation as we don't have full access to database and it may lead to increase the turn around time.
    
• Sanitize user-provided inputs
  • Properly escape those characters which should be escaped.
  • Verify that the type of data submitted matches the type expected
    
• Don’t leave sensitive data in plaintext
  • Encrypt private/confidential data being stored in the database.
  • Salt the encrypted hashes.
  • This also provides another level of protection just in case an attacker successfully exfiltrates sensitive data.
    
• Limit database permissions and privileges
  • Set the capabilities of the database user to the bare minimum required.
  • This will limit what an attacker can do if they manage to gain access.
    
• Avoid displaying database errors directly to the user
  • Attackers can use these error messages to gain information about the database.
    
• Use a Web Application Firewall (WAF) for web applications that access databases
  • This provides protection to web-facing applications.
  • It can help identify SQL injection attempts.
  • Based on the setup, it can also help prevent SQL injection attempts from reaching the application (and, therefore, the database).
    
• Keep databases updated to the latest available patches
  • This prevents attackers from exploiting known weaknesses/bugs present in older versions.