Web Application Security!!The Bad Guys are there.

4 min readOct 8, 2023

I was asked some of the vulnerabilities and threat modeling related questions in recent interviews. I want to discuss some of them very fundamentally so we understand which vulnerabilities is exploited by the hacker and how. In this reading I will cover SQL Injection and Cross Site Scripting with a very easy examples.

SQL Injection:

Lets understand what is SQL injection. Suppose you have a query to find the user id with the help of the user name.

select id from users where username='<username>'

What if some hacker write this like this.

select id from users where username='hackin''

Now Hacker only introduced syntax error that is fine.

But what about this.

select id from users where username = ' ' OR username='dummy' --

By introducing — — we kind of eliminated syntax error but introduced a way to get the result of another user if hacker wanted.

Now look at this.

select id from users where username= '' ; DROP Table users --

The above statement will delete the user table entirely in most cases.

The simple solution to this problem could be using parametrised Query instead of inline query.

select id from users where username=@username

Cross Site Scripting:

XSS mainly stems from poorly encoded HTML .Its resembles SQL injection in that sense. Instead of providing an apostrophe in the user input we can provide angled bracket to manipulate HTML. We can manipulate to have <script> and provide javascript code inside.

What can hacker do with XSS.

Hacker can read the cookies and send them to another web page.

Hacker can even load the whole javascript code from a remote URL and run on that page.

Solution to XSS

Encode text so that special HTML characters are escaped.

If we introduced a script on the web page like this

<Script> alert(“Hello”);</script> earlier we got a result from some website however with the character encoding you would get the below result.

Make sure all words are spelled correctly.
Try different keywords.
Try more general keywords.

Cross Site Request Forgery.

CSRF is an attack by the hacker when they try to modify the content on the web. Using Post request the Hacker can modify the content and can force user to click on a link that can modify the content of the website. The weakness of the post request is that the original form does not need to reside on the same domain from the POST request was made from. It can be on any web page on the internet.

This let attacker make POST submission by tricking you to click on something on their web page.

For example lets assume that twitter’s delete operation works like a post

https://twitter.com/delete/{tweet_id}

Now an attacker create some HTML like this.

<H1> Welcome to Website </H1>
<P> Please click on the button to continue</P>
<Form method= "POST"
         action= "https://twitter.com/i/api/statusess/destroy.json">
    <input type= "hidden"  name="id" value ="123">
<button type= "submit">Continue</button>
</form>

If a user clicks on this link by an error and if there is a tweet with the id of “123” the tweet will be deleted. I know for the argument sake you could sake that the twitter would have so many safeguards in their application though I am just using this example for the sake of simplicity.

The way to avoid this kind of problem is to use a randomly generated number for every form generated that is replicated on both website response and the form itself.

Since the malicious website can’t know these numbers and also can’t manipulate web server response headers , the hacker cant’ really pretend that the request was coming from the user.

<form method="POST">
@Html.AntiForgeryToken()
...
</form?

Danger of Docker Build.

When you run a command like Docker run, docker converts that to an API call and and send to the Docker daemon via a socket referred to as the Docker Socket. Any process that has access to the Docker Socket can send API request to the Daemon.

This is a very big security gap and an enormous opportunity for the hackers. Not only hackers can run any command they like but also they can use this privilege to perform a malicious action.

How to solve this vulnerability is use Daemonless builds.

Any tool that can run in a rootless mode like BuildKit and Google’s Bazel can solve this problem.

The risks are not avoided as yet you don’t need to save any secret information in the Docker layers. Anyone who has an access to container image can access the sensitive data and that’s a security pitfall.

Please share or clap if you like this content.