web server web application site security

Hello there. This is the lecture number one for week three of CS 974. And today, we'll be starting
with the web server web application site security. So as you know that in a web application, there is
the browser site at the client site where the application is displayed, the applications interface is
displayed on the browser, and the user interacts with the application through forms by clicking
buttons and doing various other things. Such as, you know, opening, a link etc. And on the other
side, on the server side, you have the web server, and behind the web server is an application
usually written in some of the web application development language like PHP, Asp.net. And also,
sometimes they are written in Python, and C, C++, but usually, there is Asp.net or there is a PHP kind
of front end through which those other applications like Python applications, or C C++ applications,
Java applications, etc, are, you know, accessed from the PHP pulled out from the ASPn.et code. And
also, there will be a database. So the access to the database query to the database also happens
from PHP directly or sp.net, directly over from the Java, C, C++, Python, etc, also,

So when the user first, you know, types in the web application URL, then a GET request is sent to the
server. And the server responds with HTML with embedded Java Script code back to the browser,
and the browser renders it so the application front end is displayed to the user.

And then the user interacts as the user interacts with the application more GET requests, POST
requests, etc, are made back to the server. Sometimes the requests are made to other servers from
Cross origin like images or than Java scripts, maybe CSS style files, etc. So, so we can use a web proxy
client side Web proxy to see them and as you know, that we have spoken about OWASP zap or Burp
suite as some of those example tools through which you can see what requests are being made the
entire request, you know, the HTTP messages that are going back and forth, you can see them.

Now, the question earlier, we the first two weeks, we have discussed various aspects of security on
the client side and most important of which was the SOP or same origin principle. And with the help
of same origin principle, we try to protect the integrity of the DOM, where the with particular web
pages or web application front page is parsed and kept in a data structure. So interference between
these different DOMs is kept to a minimum by applying SOP but in some cases, we have seen that
the SOP has to be relaxed or or bypassed because of the need of the application. And we kind of saw
what are the different security aspects and as well as we have seen, what are the attacks or what are
the security vulnerabilities that may occur because of bypassing the SOP.

Now, what we are going to see is that the application that PHP or asp.net, or you know, other
languages on the server side, if they don't do certain things, if they don't take precautions about
certain things, then various other server-side attacks can happen, which includes XSS, which includes
CSRF or SSRF. The Cross-site request forgery or server-side request forgery, we also see the
injections like command injection or the SQL injection these kinds of attacks. So we are going to only
focus on certain attacks there are many different possible Next on The Server side, but just to give
you an idea about some of the major attacks that happened and we have already seen the statistics
of the attacks that we see are statistics of the vulnerabilities even if it is not attacked, there may be
vulnerabilities that nobody noticed, but it might be exploited in case somebody notices them. The
major one of the major one is of course, the cross-site scripting. And also we saw CSRF is also pretty
prevalent.

We also see command injection or SQL injection also happening quite a bit, although in the latest
years, you know, backing in 21, or 2022, we see some of these attacks have subsided a bit because
people are more aware during the design of the web application. And also, people are more, more
and more using various frameworks or CMS, or content management systems, which have built in
functions to protect against some of these attacks and some of these vulnerabilities, and therefore,
we see less SQL injection less number of CSRF, but the XSS remains quite high. And CSRF also
remains quite high. So we will be talking about those.

And in this lecture in particular, we'll talk about command injection and SQL injection. Because most
web applications have, you're running maybe with a privileged account, the application with
application, maybe learning with the privileged account or the database connected to this
application may be running with a privilege database administrator account. And therefore, if the
attackers can somehow fool the PHP code or BSP.net code to pass this,

you know, inputs from the user as the user types in something Web application, and if the user is
malicious, then they can actually create inputs, which if not sanitized on the server side, they can be
fooled into executing code on the on the machine itself, the server itself, which lead to command
injection type of attacks, sometimes it's, you know, you can create a shell, you know, bind shell
inside the server so that you can later on have a backdoor to connect to the server.

And also, we'll see that some of the inputs from the user also get becomes part of an SQL query in
the back end that is on the server side. And if the query with the user input is not sanitized (How this
is done?), then also you will see that the SQL injection type of attacks can happen.

8:07

So, this is somewhat similar to what we have seen in the buffer overflow, integer overflow type of
situation where user input will give not sanitized properly and used in in executing some commands
or executing something, then we see that attacks buffer overflow can be done.

Similarly, here also other than command injection and SQL injection, if the backend application has
buffer overflow, that also can be can be exploited through the similar techniques.

So, we will not be covering all the possible ways these things can happen. Because our goal is to
actually get you familiar with the you know, the web application security aspects. Further
knowledge, especially if you are one of the web application developers, you might have to study and
read up on various other ways this can happen. Our idea is to actually make you familiar with the
fact that because of the client server nature of web application, and the fact that the Clients that is
the front end on the browser often takes inputs from the user, or most of the times, you know,
anybody can actually open up that particular application, especially if it's a broadly used application.
They can actually use maliciously formatted inputs in order to build command injection or SQL
injection type of attacks, or the types of attacks in using buffer overflow, etc. requires further
knowledge about the application in the backend, and whether the application has buffer overflow,
and how the inputs actually get used. In the applications in the backend, so, those are a little further
complex activity and they are possible and you should certainly be familiar with them. But, as far as
this module is concerned, we are only focusing on some parts of this some aspects of this web
application vulnerabilities and how they are exploited.
So, let me share my screen now. So, so, we are starting web server with application cybersecurity
and our first two attacks are command injection and SQL injection, these are the common
vulnerabilities. Now, if you if you go and look at the OWASP top 10 of 2021 they have reorganized
how they actually describe or count the top 10 attacks. So, if you see in the 2017 one, also in 2013
one SQL injection was one of the top 10 But 17 They actually put them in the category of injection
and even in 2021 they are in the category of injection. So, injection could be command injection
could be SQL injection, it could be other type of injections, which are actually going to create buffer
overflow or, you know, . So, they're all categorized inside injection. So, what we are talking about
today is actually in the injection category.

Now, some of the injections could also be like SQL injection could be also related to broken
authentication. For example, if the incident and passwords are stored in a database, and when the
user logs in the database lookup happens then through an SQL injection, you can fool the
authentication mechanism also. So, in some sense, some SQL injection can also if the authentication
mechanism is based on a database and making database query to figure out whether the username
password matches in that case, you can also do that kind of attacks also through SQL injection.

Also, sensitive data exposure sensitive data exposure is you know, the currently the sensitive data
exposure is kind of clogged inside identification and authentication failures. So, even the you know,
to SQL injection, you can actually dump the entire database in the backend, which you are not
supposed to get you are supposed to only use your username and password, but through SQL
injection, you can you probably can get the entire table of a database dump to the to the front end.

So, in such cases, you know, a you know, the sensitive data exposure would also be considered, you
know, in the SQL injection as well.

So, as you So, the main point is that 2021 They have done very cross, you know, vulnerability classes,
you know, clubbing certain things together into a little bit more generic category. So, exactly, SQL
injection and command injection is, you know, whether it's just confined to the injection category or
other categories, for example, in secure design, for example, the number for embedded 21 Less, that
can also be the command injection SQL injection happens because of insecure design on the service
application side. So you can also put that in there.

So therefore, as we learn individual vulnerabilities, we may not exactly map them to a single
category of top 10 attacks or for OwaSP for 21. But you know, you as you learn about the attacks,
and see what all can be done through that attack, and then you can see them mapping to multiple
different categories of topics.
So, the three main vulnerabilities that we'll discuss in this module are

1. SQL injection,
2. CSRF, and
3. XSS.

So you have been hearing about CSRF and xss quite a bit in the front end also, because a lot of it
happens because of the stolen tokens in the front end, or somehow the injection of injection of
JavaScript into the HTML that comes back from the application server. So therefore, it has
connections to the front-end quote, A bit.

But let's focus today on SQL injection.

So, the idea here is that as the user fills a form or a, you know, put in, does some input, put some
input into the browser through some form or other means>

, then the browser sends that input to the server.

>And the server is poorly designed application, they don't check the sanity of what is being input and
use that input directly into forming an SQL query.

>And therefore, might actually, inadvertently the back end will make more query than or a different
query than what was intended,

>and therefore, the database accordingly, response.

>And then database response will be sent back to the browser in the form of HTML as a response,
which will be then rendered for the user.

> Now, if the database dumps an entire table, as a result, then the back-end application, it has a way
to check the output of the database to see whether it matches expectation,

>then they can actually stop it from being sent back to the browser.

>But most applications, database output is actually directly, you know, converted into an HTML in
some form, or table form or whatever,

> and then sent back to the user, and therefore the user gets more information than was supposed
to be seen by the user with his level of authentication.

And that's how SQL injection can happen.

So, let's so it's good is basically the, I assume that all of you know what is cool is what is the standard
query language. And this language is used for relational database queries.

So nowadays, a lot of the web backends do not use relational databases, they used other kinds of
databases like Maria dB, so no SQL databases. So therefore, some of these techniques may not work
there, but they are they're also query. So, their query process also will be similar, some query has to
be formed by the application front end, sorry, application back end, and then that query has to be
sent to the database and database response.

Now, if that query can cannot can somehow be manipulated by giving a very purposeful, you know,
malformed input from the user,
then even those databases can also be fooled into giving more information or wrong information or,
you know, unintended information back to the users.

So so the idea is very similar for no SQL databases, also, that the input that the user sent to the
server that needs to be first checked. For sanity before they are used in structured in some kind of
structuring some kind of a query to the database, so otherwise, wrong, things can happen.

So let's look at command injection first.

And I'll show you some examples on the DBWA database in a subsequent video. So today, we are
going to first look at these things in a theoretical manner. So command injection is basically a
precursor to say SQL injection. Because if here also if the user input is used in executing a command
on the server, by the by the web application, then if the web application does not shake the sanity of
the input being sent to it, and include that into the command execution, without removing the
offending part, then it can have disastrous consequences.

So So let's look at an example of very simple PHP based web application. So, in this case, we'll see is
the calculator application, right? So here is the site.com, where the calc dot PHP is a is a web
application written in PHP, where the code inside this PHP file is looked somewhat like this. It takes
the expression so let's say in a front end, I have calculated and I have the box where I am supposed
to input expression. So I can input I can input like two plus three times five here. And then I'm
supposed to get an answer here, right? So, so that's the order in a different way. So, so in this case,
the answer should have been 70. So, but what I type in here, unless there is a special check that
what I type in is indeed an expression, and not some other commands, etc, what can happen is what
the point is. So, here,

so what is the what the back end so when this goes, the expression goes, it goes as expression,
some feed in the data, so, it probably goes as a post, as opposed to, or maybe it can be put in the
query part of the get request. But then in the back end, we the Gallup dot php file, how does it
process it, so it takes expression. So it says, Get expression means, you know, read out the
expression, put it in a string, that is in it's a variable, and then it is saying that eval. And then you are
saying that, you know, you have this eval allow. So the eval, you have some variable name equal to,
then you have the expression, the string for the expression, then you have that semicolon, right. So
it is going to actually execute this URL on the on the shell, it will invoke the shell and it will evaluate
the, the onset and then what can happen. So it's basically taking the same that go on there is
nothing that shapes the index raishin is manipulated or some malicious expression, just trust that
the expression will be a numerical expression and therefore it is directly using it in evil. So, so it will
be the this thing will go like this. So it may go as a GO GET request. And it will be basically sending
that whatever the expression here is, now if you type instead of two plus three times five, if you type
some expression, semicolon, then you're calling the system and saying remove star dot star. Now
since the eval will see this system call eval will actually, you know, make a system call, this is the
command for removing files. So it will remove all the files from the directory at which this calc dot
PHP program is running. So in that process, it will also remove the correct dot php, and then the
calculator program will be broken.

So another example here is that suppose you have a website where you ask the user for his email,
you might have seen this in many news websites, where you are allowed to make a comment or
something or any other website where you're allowed to contact the helpdesk, or the customer
service to by putting your email and subject. Subject allow, and then you might have some kind of a
box to put in your information. Now this, again, this emails, whatever string you input here, XYZ,
back abc.com. And here are subject to maybe Thank you. And here, you might have something and
then you all this information goes back to the backend server, PHP file to the web server in the PHP
file, now reads this, so it again, it will enter the post request. So from the post request, the PHP
recovers individual fields by doing this, and then what it is doing is in this case, we this part seems to
be not there in this wave application. So this is an application for sending you an email and maybe
some subject and then accordingly the subject, the An email will be sent and the email body will
come from, we'll be joined by network are kind of thing right? So this is kind of like let's say it's a it's
a social it's a social not nowadays. Is it differently, you make a request to others to become your,
your network, friend or something. But early in early days, what would happen is that, let's say you
want a particular friend whose email you know, to be invited to join the network. So you, the site
gave you a form, in which you can say, the email and subject customize subject, because you can
say, Hello, this is me, Sandeep, and I want you to join my friend face network. And then the post
request is sent. And then the backend PHP now reads the user input email and user input subject,
then without here, it should be sanitization code, whether the what whatever the email and subject
are, it should actually see that that that is in the right form, but in this code particularly, you have
the a there is a system call, which will basically invoke the shell to actually execute the main
command. So main command in Unix basically works by me with the email address, in which case,
we will add this is taken from what you typed minus is the subject the subject will be taken from
what you type. And then this one would be a very generic statement saying that I am using this
network and why don't you join this whatever, but it will come from a file in the server.

So this is a highlight the server now what can happen so attacker can post email to itself, its own its
own email address, and subject in the subject, it creates a malicious input it says. In this it says that
su but there it says this, right and then give me the user slash password or any any file if the PHP
program is running with the right privileges to have given also etcetera, password, which will only be
seen by the high privilege account, and then maybe the any other comment, so the semicolon any
other shell command. So another possibility is that the user, if the, if the PHP file is running with the
root privilege, then what you can do is that you ask for your email address in the subject, you use
something then semicolon, then you say equal then a an entry into the slash etc slash password file.
And now if this user the PHP file is running with the privilege of a highly privileged user, then this
command will this equal and then double redirection into Exeter password will basically create an
entry into the slash etc password where the basically user name is equal, the password is blank,
right, and then you have the you know, other things and then it invokes the, it has the, it has a root
privilege. And when it when it locks in, it invokes the regular shell. So now what will happen is that
when this command gets executed on the, on the server, the server and provided this PHP file is
being run and it will basically create an entry in the cache etc paths path slash password, and
routine, which in effect will create an account evil within the username evil, no password, and then
with the root privilege, and therefore, the user now has a back in a backdoor into your system, he
can then remotely log into your system, provided of course you have other ERP is just HR tells me
something open otherwise the user cannot get into your system. But how you know you hear that
end user can NMAP and see if you're running SSH or or telnet. Then he can try this and then get into
your machine factor with a root privilege, right? So you can basically get all the stuff on your account
on that machine under the root privilege and then you can Do it basically anything on that machine.

So OS command injection, also, called Shell injection, is a vulnerability that allows an attacker to
execute arbitrary operating system commands on the server running an application.

And it's typically fully compromised application and all its data. But also if it gets, the attacker can
get a shell that is privileged shell. So you can also get a on that privilege. Not so privileged shell, if
the PHP was running in a specific user account that does not have root privileges, then you can do
limited damage, but if the PHP was running with the root privilege, then you have like saved
wrestling with the sudo or something, then you actually have the, you know, compromise the entire
server.

So an attacker can leverage and with command injection, to compromise other parts of the hosting
infrastructure, in case you know, you have a high privileged shell. And also, in that case, it can also
exploit the trust relationships like the server machine may be connected to the other machines, and
there will be trust relationship, for example, in the remote hosts allowed to connect to another
server from this server is probably done through no authentication, right. So for example,

.Rhost files in Unix, will actually allow certain hosts to actually connect to that server without, you
know, having password.

So in that case, once you have the privilege on this machine, and any other machine that has a trust
relationship with this machine can also be compromised by the attended by exuding relevant
commands.
So that's the, that's the command injection problem. There are other examples of this so so let's say
you have a shopping application that in the shopping application, you basically have put in a product
ID and store ID and see if this product is available in that store. So let's say this website is not
designed well. And you can ask, because we do, so, you fill in this 38 here and 3029 here and then
the the applicant in the JavaScript here creates a request back to the server with this query. Now,
the application must query various legacy systems in the backend the now suppose the application
when we when it goes to the backend application with these two inputs.

So it may be exhibited with another file, in this case, this is a Perl script. So let's say there is a legacy
Perl script with which you should give this to inputs in the basket executes does database query
whatever right. So, this is the let's say, this is how it is implemented in the backend. So, in this case,
instead of you know, frame 38 here or 381 here or 289 Here, if these fields are not sanitized before
they are passed on to this ----, then it what can happen is I can give arbitrary commands here also
and when I do arbitrary command,

so, let's say I do this impose some something. So, just to just for checking whether the command
injection works later on, I will give more interesting more potent commands, but in this case,
suppose you want to just see whether we depose back something.

So, it will basically create this additional since this is a command on the shell, so, this command can
be also joined with other commands and the shell will execute them as in that sequence. So still will
execute this command this one will obviously not in a insert any response, but this one will actually
create an equal.
Now in all these examples that I just showed, you saw that the as I do the command injection, if the
command injection succeeds, then some in output comes back to the web, front end, right because
So, after the comment succeeds reply is generated back to the front end from the server, and that's
an HTML code in which this output will be embedded right? Because the application was intended to
do that with that, in case of legitimate inputs, we do not tell you see the list of products, or it will tell
you about the that your email has succeeded, or it will tell you the answer to your calculated
expression that you calculated. So if you include other comments along with it, then whatever the
output of that command will also come to you. So you can see it in the front end, and you can be
sure that some something has happened right. Now in in this case. So blind. Waste command
injection is the case where I do the command injection, but the command injection output is not
shown to me on the web front end, because no reply comes back. And in which case, I don't know
whether the command injection actually worked or not. So I tried and malicious input. And I went to
the server says Sir, how the how the backend code, we then sanitize the inputs, and therefore my
command was rejected, or whether it didn't sanitize input, the command actually executed, I have
no way to know then that's why I'm blind. So in in such command injection, we call blind command
injection. So the the definition is, of course, the application does not return the output from the
command within its HTTP response. And the blank vulnerabilities can still be exploited, but different
techniques are required to know whether it succeeded. So so consider an example of a blind domain
injection. Suppose there is a website that lets users submit feedback about the site. So user enters
the email M feedback message, the server side application that generates an email to the system
administrator containing the feedback. So there is nothing that comes back to the user saying that
your email has been sent or something. So that's not how the application was designed. So the
application just takes the user input and does its job in the backend, but no response is sent back.
So, in that case, if the this this backend, PHP or ASP dotnet whatever does not sanitizing inputs, then
you probably can do OS command injection, but how do you know that the command injection has
succeeded because what will happen is the back end will do something like this, it will invoke a shell
command when mean minus subject from what your email address the one that you that you typed
in, and then it will send it to the fixed some fixed email address for feedback. So, output from the
main command is not returned in that applications responses. So, the person who is trying this does
not know what happened. So, so, there must be some other way to know whether sublime
command injection has succeeded. One way to do that is to use time delays. So, you can actually in
the inject code injected command, you actually also add a time delay for example of ping. So, you
want to let's say, you know, delete all files as your malicious command. And after that, you use a
semicolon or ampersand a percent and say ping to So IP address. So, if you if the command if the
data is sanitized and then both your Delete remove started star and your ping command will be
removed before actual mail is sent right. But in case the command injection succeeds, that is the
backend is not sanitizing the input in that case both your vision as well as your being will succeed
and then the ping will take some time right and when the pain takes time and if without the pain,
the you know the will immediately you know come back right with the pain, the response will come
a slightly delayed right. And if you can somehow you know since that delay, then you know that
whether the command injection succeeded or not, so this is called that time delay based detection
of command. Line command injection sucks. That's. So, so, here is an example. So, you do a ping if
the, if the machine target machine that is server is Windows, then you can just do you know ping
because in Windows ping only does it three times or four times, but if it is a Linux machine or some
other sort of other other type of operating system there the ping without a you know, without
restriction on the number of times the Ping has to be done you know, it will keep pinging and you
will never get the the website will become non responsive. So, so, therefore, you actually add doubly
double enough numbers so, that the delay is enough to add this additional thing to the command
you want to execute, if the if you see a delayed response, you know, coming back then you know
that the command has been executed. There are also so, this is this is a technique that is through the
browser itself, you are trying to figure it out. That way or command injection succeeded. But also
there are some ways called out of band technique out of band technique means that in your
command injection, youserver-side do your malicious command and then add with that something
to the effect you can see, right for example, you can do the command injection and then put an
ampersand and say NS lookup for a particular for a particular website, which is not usual, right? Like
here is a randomly generated web sites that you want the NSA. Now, if you have it, you can watch
the, let's say it's a network who's whose DNS requests are actually observable by you. Right. So you
have, you can see the DNS servers. So so therefore, you know, if your command injection succeeds,
then you will see this DNS request for this domain. And then you know that your command injection
succeeded because if your command didn't execute on the machine, it was sanitize. And so now that
in that case, nobody, it's very unlikely that they will come application inside the server is looking for
exactly the this random website, right. So you can assume with very high probability that this
random looking website is being requested for DNS lookup, because your command actually needs
security. So this is called the out of band technique for for detecting whether your blind command
injection succeeded or not.
Okay, so that's the, you know, the basic idea of command injection. So the basic idea here is that the
backend server-side application takes user input. And somehow, the way he uses the user input
involves something, something to be evaluated or some shell command to be executed. Now, by
knowing that somehow you can, or guessing that you can actually create a malicious input. So that
on piggybacking on this evaluation process, or piggybacking on this, you know, follow up call into
some kind of shell command, you can actually execute your malicious shell commands or malicious
things, get a system call, so that you can do harm to the back end. So this is kind of coming in action
will show you in the video where we actually showed this on the DBWA, that I can also use this to
actually create a permanent file on the server.
For example, I can actually do an echo
then a shellcode,
and then redirection into a file name.
So a file will be created on the server.
And then I can later on, make use of that file as to execute shell commands.
So I can I can actually create a PHP file on the server just by making use of this command injection if
there is a command injection vulnerability,.
and then I can refer back to that file, access that file to execute other commands.
So we'll show that example when we show you when you show you DBWA examples. So now
moving to SQL injection.
So as I said that it's Again, in such skill, when is a split query executed in the backend, when the
application has a front end where it takes some input from the user, for example,
1. a login page, you have username password that the user inputs,
2. then that goes to a post request to the backend,
3. the backend then has to look up this information that is there in my table, a database table,
let's say users, you do have a i have a row where the user name is password is or encrypted
version, or a hashed version of the password is in the table.
4. So in order to do that, you have to basically take the user inputs, and form an SQL query.
5. And then then ask your database connected to execute the SQL query and
6. you get the response to the SQL query with the SQL query,
7. it comes out to be successful, then you know that we that user name has that password and
you actually,
8. you know, allow the user to, you know, you consider the user authenticated,
9. and send him a session ID or token, whatever.
 So now, in this example, let's say I have a sample PHP code, which is poorly written.
1. So how can it be poorly written,
2. so, what this guy is doing is that it is reading the user input into a variable,
3. and then using that variable directly into the SQL query formation. So it actually is creating
an SQL query sets a string,
4. within that string, it's actually using this variable.
5. this is a PHP code.
6. And then it is actually calling its database connected to execute the query as formed.
7. And results are withdrawn here.
8. Now, if the recipient is a malicious string, that changes the meaning of the query,
9. then what will happen?
10. So for example, instead of instead of this if the recipient, so let's say the recipient is
Sandeep, so then I type some deep in the box in my front end,
11. and that information goes there.
12. And here basically, a user name equal to Sandeep it will be put in,
13. but suppose I instead of Sunday by say, Sunday, then I complete this code, because I know
there will be a code here. So by putting a coat I'm basically completing the code
14. and then I'm saying or one equals one, now, one equals one is always true.
15. So this query will basically select all Person ID from the from the person table, where
because your condition is always true, the condition even if it is not Sandeep, any person
you know it will be matching one is to one equals whenever I can actually instead of using
Sunday, I can just say, quote, here again, right food one. So yeah, ---- I want to finish this
condition, then I do, then I say, four, one equal to one, and then I have to give up Hatch dash
dash, dash, dash dash will ignore the rest because I have an additional code here that needs
to be ignored. So I finish this code with this. And then I say all one is equal to one. So that's
always true condition. And then I put a hash or dash dash, which will ignore this additional
thing, otherwise, the SQL query will be wrong, you know, syntax. Now, the reason why this
will succeed is because when I typed in recipient and it was sent to the server server didn't
check whether the input makes sense. Because if the server saw that I gave something like
this, the server would immediately reject should should have immediately rejected that that
input, because it's obviously an attempt to manipulate the SQL query that will be formed at
the application site.

So so the way it works is that the attacker, he basically loads the victim application, front end
there, it sees the Box or whatever where the user input has to be given. And then he basically
instead of giving a proper input, it gives an input that can induce a different SQL query than the
one intended. So it sends the malicious input through the post request, the server then forms
the forms SQL query and sends it to the SQL database. And then SQL database will basically be
fooled into giving out information. And then that information will be sent back to the, the
attackers browser, because you're supposed to send even for regular queries that are not
malicious, the output of the query is supposed to in some form go in go into the HTML that will
be sent to the attacker to the to the browser, so that it is browser will get data that it is not
supposed to get. So
So SQL injection attacks are very common if you go to the NBT database. And if you actually look
at the SQL injection, you know, CVS, you will see even today, there are lots and lots of SQL
injection series, there was a company called Card Systems, it was a credit card processing
payment payment processing company, we'd had an SQL injection attack in 2005. And it was out
of business because more than two lakhs two and a half lakhs pre cut numbers were stolen, the
information was not encrypted. So, lot of people's created numbers CV expiry date, etcetera,
went to be adapted and pasted. So sold it and therefore, you know, the company had to pay
penalty, etcetera, etcetera. So, therefore, it went out of business, and they had 43 million
records in the database only this much was exposed, but there was a scope for 43 million
records being exposed. You can also read this, this particular article about what importance of
SQL injection even today. So, and if you go to the database, the CV databases, you can see and
even make a query about SQL injection, you will see, you know, 1000s of them. So, so it's been
very, and many of them are pretty critical, like 7.5 is high criticality, and therefore, this is to be
taken seriously. For here is a real example of a buggy login page.
 So here is so on the sample site, the ASP code is saying select everything from users where user
and then they're forming the query by actually reading what what was typed in by the user and
in the username and password. And then if not, okay, then login success. And it basically okay.us
If the okay is ended up fine, then it's not a success, if okay is not in the file, then it's a success.
Else, you're not failing, right. So this is is this exploitable. So here, basically, the browser, you
enter user name and password, post request goes to the web server, web server informs this
query like we do that using this code. So it's basically select, and then here is copying exactly
what was typed in without checking the sanity of this. So it's a normal query, if it's a normal user,
I do normal typing normal name Normal password, but a malicious guy can actually do
something that I already was discussing. To complete the code on the user name. The additional
input is given as a quote, so it completes out the user names part, then it puts another condition
to an oar. And this and this dash dash is basically the name of the comment commenting in SQL.
So everything every additional code that was completing the user name, as already been
completed with this, this additional code will remain but it shouldn't be ignored because of dash
dash. So the script basically now have select blah, blah, blah, away user. Here you see an empty
user or what 12 to one, one equal to one is always true. So therefore, this condition will always
be true. So it will still select star that is all, all the content of every row of this table and send it
back to the browser. So whatever is at the browser who actually typed in this malicious string,
will actually be able to see the entire table. Now, this is very, very common in 2015, when I came
to the came to who we had, we drag this first in our grade database, and the lo and behold, the
Password field. On the password field, we couldn't do this. So we I typed an arbitrary password
to a port, or one equal to one, and then I can become anybody. So I couldn't become Professor
X, Professor why, and see what they read entry. And all that. So So So then after informing the
people in charge of this site, they said, Well, we fixed it, basically, they first this was reported by
other students before, but at that time, they found the problem with the user field user field had
could take this, this or one equal to one, and then the then the password field was not even
being checked. So they fixing the field, they actually beat some sanitization of the user field, but
they didn't realize that if they are doing it for user user fee that they need to do any other field
that is going to be used perform the query. So then, obviously, we found at that time this,
fortunately. So the question then is that if this bug was there for a while, did the students use it
to increase their grade etc. Now, fortunately, the process of reading into it is a little bit strange,
that is, during the after their final exam of a semester only for a short period, this site actually
opens, another time, this site cannot be accessed or any of the faculty accesses, you cannot
enter grades, he or she cannot integrate, she can actually only look up the past grades
yesterday. So there was no way to change anything. So for past grades, the site was safe,
because there was no way even if you log in as Mr. X faculty X, you cannot change your faculty, it
is great during them throughout the semester. Now during the two, two day period. So back to
the period, maybe one week period, when this is open for inputs by the faculty, then, if a
student actually who is actually taking a class, at that time, can actually and if you knew this
technique, then he could have accessed and change the grade. But there is also a catch, when
we enter the grades, we actually do submit. And once I submitted, then it says authenticate the
date, so I have to click another button, then that becomes read only, right? So assume assuming
that a student is is trying to do that, but he's window of opportunity is very small, because within
that seven day period, if the faculty has not given up has not given any game yet, then the
student cannot go and change his grade because it will look suspicious in the faculty logs in you
will see that I haven't even started giving the grades and there is an A in one row, then you will
obviously know that something wrong has happened. The other protection is that after he has
given the grids normally we do this in one go. And then we some click some used to now the this
whole system has changed that we used to then click submit and then authenticate. So normally
you do that in one city. And you already have prepared the grades in some Excel form and then
you actually are typing them in. Now in this case, while the faculty is doing the first students
read until it reaches the last to them, that window is very small. So during that window if that
malicious student gets in and changes the grid, maybe then change the grid. So that's a small
window of opportunity, which is possible which was possible at that time. But the risk of that
was considered very, you know, very low because faculty within a period of 24 times seven
hours, as if it's a seven day period for them, we don't know when students will know when the
faculty will actually log in and input the grades, he has to actually reach the system at that, at
that specific time. But, but then, the other question was that, that, that after the grades are
submitted, the system mails, the list of grades to the faculty. And then if the faculty sees that
some student he knows could not have gotten an A, or whatever, in the list sent back to him,
that student has an A, then of course, you will have a red flag. So there are many different ways
we analyze that the risk of a breach is was very, very low, but it obviously we don't want to have
any rescue. So we had to fix it. So we fixed it. And now a completely different system has been in
place since then. And which has sanity check, and we equity on it, and so on. So there's no SQL
injection right now. But there was a time when this was happening. So the reason I'm telling you
this story is not imminent, the reason I'm telling you the story is not to say that, you know, we
have a problem or but but rather, I wanted to show you that even, you know, simple systems
like a great management system. If the designers of that application is not well aware of the SQL
injection possibilities or the need for input sanitization all the time, then such bolts will remain in
our system. So similarly, you know, the user can actually piggyback, you know, this cord, and
then drop cable users. So, this will delete the entire table, entire table, which will lose data, and
maybe recoverability, if the database is not backed up. So, in this case, the on that code user is
equal to something then semicolon, then a command to drop the table from the database, this
could then dash dash, and then you have rest of it is command a command it commented out.
So similarly, an attacker can also add users reset passwords, all kinds of stuff, right. So he not
only can he can say, to insert, bla bla bla, into the table and the inserted it can create a backdoor
user into the system. Similarly, if the user, you know, in the user sleep, you can exit command
shell, and then you can exit this, this will create a user with the chosen name of the of the
malicious guy with the chosen password. So it is done through an exec command shell, in case of
you know, so it will basically use the net command on the on your on your server. And if the SQL
Server is running as a system administrator, so that attacker now have account on the database
server, so that's basically can then access the database server as as a system administrator,
which will be really bad. So here is a tutorial representation of an SQL injection. So the user has
the front end where he has to type in several things. And this is the front end. And the user is
typing in, in the field of something when he thinks there might be an SQL injection, and typing in
SQL command Union command. So union, and then select username and password from users.
So this will actually whatever is being retrieved along with that offset union of whatever is
written to this query. And this query will give you that username and password for all users. Now
if if the user's password is stored in the database unencrypted, then we have a problem, right?
Because then we'll have this you know, the user will get back the entire list of username and
password if it is encrypted. If it is hashed, the password is hashed. Even then that get the user
will get the hash of the file. switch could also be detrimental, because dictionary attacks or
rainbow attacks can reveal some of the weak passwords. So, so that so anyway, so as the user
types in this and then presses the submit button, a request is, you know, this, this input is going
in the as part of the use part of the field, whatever field. So, in this case, the field was category.
So in the Category field, so, there is some input, then a petition, this connection, there is a union
select username and password from users. So, this entire query will now be sent to the database
engine. So, the database will execute and give you the, all the username and password from the
users table even though the original query was supposed to be net products team. So, you will
get all the passwords back through back to the user through the HTA, there will be embedded in
all usernames and passwords will be embedded in some form in HTML. And it'll come as a
response from the from the backend server, the web server, and then it will be rendered on this
base page. And this guy will be knowing all the username passwords, or at least the hashes of
the passwords. So here is a old cartoon. This is, you know, just a, you know, comic relief. So here
is the mother is getting a call from the school son school. And they are saying this is your son's
school, we have we are having some computer trouble. So, mother is saying, Oh, dear, did he
break something? In a way, so says the school then the school says, Did you really name your
son, Robert, quotation mark, you know, parenthesis, semicolon, drop table, students, semicolon
dash dash. So these are these are tied to right, so the mother named the son this. So therefore,
when, when a query was made for the sun, it created a SQL query that dropped the students
table from the database. So Mara said, Oh, yes, little Bobby Tables to call him. So Mother, this is
the formal name and the mother calls little Bobby Tables. So what school says, Well, we have
lost this year students records, I hope you're happy. And then the mother says, and I hope you
have learned to sanitize your database inputs, some mother is probably a web application
designer or something. So she's actually, you know, taking it that way that you know, I can name
my son, whatever, even this, but you should know how to sanitize the inputs before you form
your SQL query.
Anyway, since it's just now there is also something called Blind SQL injection like blind command
injection, right? To where you want to make a query to the database, but the database does not
necessarily respond which something to HTML to your browsers. So in that case, you don't know
whether spin injection is, is working or not. So you can form a query like this, like, for example,
let's say there is some field category or something where you have to give some input, then you
are piggybacking this additional query to a union. So you're doing a union and this query, select a
now see, this is a literal, this is not something in the cable, this will always be out. But we are in
your query is that from users table? If the user name is past administrator, and his passwords
first character is greater than m, m, so you can compare characters, because characters are ASCII
values, right? So so let's say you, you want to know if the password, you want to know the
password, right? So let's say of that newsletter, and you have, you don't have a query to dump
the password of the administrator. So what you're trying to do is that you're trying to actually
get the password to some kind of a binary set. So you want to check whether To get that first
letter is better than em on. So then you know that then your choice choices will be to check
whether it's in or B, q, r s, t u, v, w x, y Zed. So M is kind of in the middle, so it's like a binary
search. If it is not greater than m, then you know that you have to search in the previous letters.
And in this case, the output will always be a, if the, if these conditions satisfied, otherwise,
there'll be no. So by creating a query like this, where either your output will be a the letter A, or
will be downloaded along, alright, so on the front end, and he will go if this succeeds, otherwise,
if he doesn't see the A, so the attacker will, once he succeeds in this editor knows that it is
greater than m, then it can do another query, because he has the front end, whatever the form
or whatever. So he can actually make another query where he says the same thing, but you want
to know what that is, they have been t. So after m, is again doing binary search. So whether it's
greater than p or not, if it is not greater than he knows, it's between M and T. It's a jetsetter So,
in this case, also if it succeeds, if that is if it is indeed greater than t that A will go in the output,
otherwise nothing will go to it without union end, then that, then once it is suppose it succeeds,
then he wants to see whether it is equal to s. Right? So so if it doesn't say, if it feels that he can
actually now start doing equality comparison, so this is a rather silly example, but this is to show
that if the query like this query, select this query, is what you are looking for, but you are not
able to get an output from the query. So you've given literal, so that if he were very successful,
then you will get something. Right. So so that's how we were doing figuring out whether you're
blind is an injection succeeds, and

you can also do this other by other means, like for example, for the same query, instead of
saying that select a you can you can create an error condition. So, if it succeeds, there will be an
error, because you are you're asking it to divide by zero else null from users right. So, so select
case when, so, this is a use kind of an if statement like switch statement. So, when this condition
is satisfied, then induce an error or else do nothing from the user state. So, in this case, if there is
a one over zero that is divided by zero exception, obviously, the output will show obviously, the
front end that information will go to the front end, this is an error message. And then he will
know that it is then that this query was successful, you can also create a conditional time delays
like you can say, from users and messages substring is this if this is one, then wait for delay, and
then give some delay here. So this is this is a, you know, legitimate SQL statement. So RBA if the
if the webpage comes back with a DA then you know it succeeded. So, either you do induction or
you do time delay induction. So this way you can make a query where you are trying to figure
out something some information from the database, but it is not the European is not generating
outputs.
So there are three ways we saw in one case,
1. you give a constant output in the query succeeds.
2. Or if you use a induce an error condition, so user error condition, when the query
succeeds, or
3. you induce some kind of delay in the query succeeds in all cases, you can actually from
the front end, you can have some idea that with a got executed

now, the question is, how do I know that? We don't I don't have the backend code, right.
So, I don't know what PHP code is running on the server side.
So, I have to guess whether I am actually having

whether the field that in which I'm supposed to give user inputs Whether they have SQL
injection or not.

So, usually this is done by attackers through various trial and error methods.

So, one thing is that one common way is to give a single port and look for errors or other
anomalies.

So, let's say there is a free user name and then in the query it will be already and then
there should be a variable you know user and like this in the query.
So, if you instead of a real name, you give a code, then you will get a quote right. And
then you will get an Instructure you will get a thing that we are very structured, there is
a syntax error, because you have an extra code here. But if if the if the input was
sanitized by the by the back end, then this code will go away, and then you get a you will
not get an error message, it may be an unsuccessful query, but because now your user
will be empty, but it will not be a syntax error. So therefore, it induces a syntax error or
something, then you know, that this code character was actually inserted into the SQL
query by the back end before sending it to the SQL engine, also submitting some SQL
specific syntax that evaluates to the base value of the entry point, and to a different
value. And looking for systematic differences in the resulting application responses. So
you can try to actually do some SQL syntax that evaluates to the original value of the
entry point. That is, whatever the real user name, and then you try it with a different
value. And you see that what's the resulting application responses are, so you can try
one is to one and then you can try some leap. And you see if there is a difference. Right?
If there is a difference in response, then you know that some SQL injection and some
lack of standardization on that on the backend.

 I realized that not everyone has fully appreciated the power and innovation of 
Out-of-band Application Security Testing (OAST).

You can also submit Boolean conditions, like as we were saying, or one equals one, or
one equal to two, and see the differences in the application responses. You can also
submit payloads designed to trigger time delays, like we were showing, or you can
submitting out of band payloads designed to trigger an out of band network interaction.
Like for example, if let's say, after this, you can see command shell NS look up something
right. So then there'll be an NS look up to you know, that this this became part of the
Queen and it's been a Indian actually did include the modified SQL query as intended by
you and not as intended by the application designer. So, you can do various out of band
or time dealing based on you know, this comparing multiple different Boolean
expressions, various ways you can actually detect blindness curls, query success,
injection success.

Now, all the SQL injection examples that we were talking about where first order SQL
injection, now, what is the what is the first SQL injection and then what is the second
order SQL injection. So, the first order SQL injection is basically means that when you
give the malicious input, it immediately have an effect on the query that is created. And
that query is now when executed will even give out additional information may change
some application, something some some rows in the table or it can delete a table, drop
a table, whatever, delete a row, whatever you are intended. So that's a first order effect.
Now, suppose somebody is wants to do a little bit of pre work after before he positions
himself to do that. So what they can do is use SQL injection to create additional entries
in the database, for example, like we saw an example where an additional entry was
created in the database And then use that for later SQL injection attacks, that the later
attack will be going is called second order is split injection, that is first SQL injection first
SQL injection will not do any other types of firms like deleting tables or exfiltrate, the
intended table data etc, but it will store something in the table and then later on in an to
another SQL injection, it will retrieve that data or it will actually use that data that is
stored, let's say it stores the evil username and email password and then it can use that
as a backdoor to you know connect itself to the to the authenticate itself to the
application, then that will be called a second order. second order effect second order is
called injection. So, this is also called the stored SQL injection. And application takes user
input from HTTP request has to sit in the database for features. So this is usually done by
placing the input into the database. And there is no vulnerability exploited at that point.
And later, when handling a different HTTP request the application retrieves store data
and incorporates in the SQL query in an unsafe way. Sometimes, even the payload for
the for for creating a bad SQL in a malicious SQL query. In the first order, is just for
storing that input. And then in the second order that will be retrieved and used in
another SQL query, and therefore changing the meaning of that SQL query. So here is an
example. Well, it's a cartoon rather. So here, what is happening is that this person wants
to create a user wants to store a different password for the administrator by fooling the
fooling the, into the first first to the SQL injection. So he has, let's say he has an he is
doing some is browsing one of the front end pages of the application where he's
supposed to put in the some user name, right. So what you will do is, he will actually,
instead of a regular user name, he uses a user name, and then adds this additional stuff,
which is another SQL query. And, you know, which which basically is an update,
statement, updating just storage statement on that SQL database. So it is updating users
data users table by setting the password of this user. Now, then what will happen is that
so this is what he has typed in that user fee. In this user field, he has typed that I quote,
semicolon, then then this entire is will vary and could say, commenting so that this
additional code gets a comment commented out. So when it goes to the backend, this
input goes to the back end, it will basically execute it and create this. The we update the
table where administrator user's password has been changed. So this has to affect when
administer to Himself comes and takes his original password, he's not able to log in, if he
was clever, and if he knows there is a, there is an SQL injection attack, you could use a
quote or one equal to one and put it in but let's say is not aware of the weakness of this
application. But this guy now has has the password of the administrator. So he can
actually do a second order attack to to get into the system. Right. So this is a second
order history. So we'll see some examples when we go to the PWA examples. But you
get the basic idea that all of this is happening because of lack of sanitization of the user
input on the front end page of the application. And the application back end, does not
do the right thing by and uses the input directly from the user. into making a SQL query
in the program. So how do how do the question is how to prevent SQL injection so so as
a as a Application Designer, you're, you're cautioned against building a squid command
yourself. So, in all the examples that we have source, we have seen where we are
actually using a spring, you know, kind of a mechanism for creating a string for a SQL
query ourselves. And we are not doing any sanitization of the inputs, and then that
string is what is called various form, part of which is actually user inputs directly. We call
the database, you know, connected to actually execute the query. So, instead of building
your own SQL commands, you know, by string manipulation, you should use
parameterised or prepared SQL. And also you can use object relational mapping
framework. So here is an example of parameterize your prepared SQL. So, in this case,
what happens is that most of the cases, this quotation mark is a big problem, right? The
use of the quotation mark, and we'll see spill injection because their quotation mark is
required to close out one of the input fields, and then you know, add additional
conjunction like or or you know, semicolon etc, to piggyback additional SQL queries. So,
if you can escape, so, when I use the slash in front of this, then this thing uses its
meaning and we will be treated as as just a character and not as a meaningful you know,
end of a fields you know, body. So, so, there are ways to actually pass a string to a to a
function, which will then go and put this thing with any additional unmatched petitions.
So, but asp.net has this, you know, facility by by if you use their parameterised or
sculpins. So, in the, so, the way they suggest is that you call this function is called
command, where you put the strings and then wherever you are taking inputs from the
user, you use this variables and these variables are actually defined from the request
from from from the user input, but this functions does all the sanity checks and escaping
of offending characters. So, if you use if you introduced this directly, here and this
directly here, then these things will not be sanitized, or escaped, etc. So, but these
functions will make sure that they are escaped and sanitized. So, similarly, in PHP, we
have a similar function. So we can we certainly, you should use these rather than, you
know, our own string manipulation to create the query. So, this passing the user inputs
to these functions before they're made into a query is is the advice at the end, or the
CMSs group Drupal and others also have different functions to do this, right. So always
use those functions to build a script with. So, finally, we want to talk about the 10 tips
for avoiding SQL injection. So, the first tip is trust no one anything that comes from the
user, which you are now going to use in a command or is split command. Always pass it
through some sanitization check or input validation check. So in case of in case of mask
MySQL, there is a function called MySQL real escape string. So any dangerous characters
such as the single port are not passed to this filtering, the data should not pass any user
input directly to a command or directly to SQL. And in case of SQL, if you're using
MySQL, you can use functions like this. So you have to look for these functions in the
framework in which you're developing your application. And you should also sanitize
everything By filtering user data by context, for example, email addresses, so, if your
input is an email address, so you can actually check the formatting of an email an email
is always something x sign something dot something dot something etc. So, you can
actually write regular expressions checkers or there are also inbuilt checkers like this in
various frameworks. So, any email address cannot should pass to that check before it
can be treated as an email address inside an SQL query phone numbers similarly, could
we also check should we also check for similar formatting and if the format does not
match, if any non numeric characters are there, if you know the number of characters,
number of numeric characters should in the phone number for the country, you enforce
those in order to ensure that it is indeed a phone number or a wrong number but not a
offending string. Second tip is do not use dynamic SQL, do not construct queries with
user input. So we already discussed this a lot. Data sanitization routines can also be
flawed, right, because somebody wrote that it isn't the eviction routine, and in a way the
programming mistake. So something remains in the in the user input, which is still which
can still induce a SQL injection. ---- prepared statements or parameterize queries or to
procedures and not the data, you know, your own build data center center, you should
reduce. Now, when you use stored procedures, they can prevent some types of SQL
injection with the failure to protect against many others. So do not rely exclusively on
stored procedures. So so usually use the prepared statements or parameterize queries.
Third is update and patch applications, databases, they all have vulnerabilities you will
see if you're using MySQL, if you're using Microsoft SQL, if you're using Oracle, you will
always have you're using, you know any kind of database vulnerabilities are published
almost on a daily basis, if not weekly basis, if not monthly basis. So you should always be
on the guard and patch your databases because some of these can be exploited. So this
is something that is very important always update and patch. And also update and patch
the framework for your web application design, for example, Drupal, or Joomla, they
often get this, you know, vulnerabilities exposed, and some of them may be related to
their sanitization routine, some of them may be related to their prepared statements or
you know, parameterised statements. So, so you have to be on the lookout for such
disclosures, and always have to patch once a day consider web application firewall. So
web application firewalls actually, you know, sit between the web server and the client
and actually on the server side and all the HTTP requests will have to go through the
web application firewall and the firewall has lots of rules like if you see this kind of
patterns then you know that this is probably an attempt for SQL injection or this is
probably an attempt for command injection etc. And various web application firewalls
are in the market but you can also use Mod security which is open source free, which is
available for the web servers Apache and Microsoft is nginx etc. And it has a set of rules
and these rules get get updated like our antivirus you have to update the rules of what
security some more indicators of compromise and known by mod security team they
add new rules to know that okay, this is a another way is an injection is happening this is
the way you know access isn't happening. So, so it adds rules so that it can block certain
HTTP requests or blocks initiative responses, because it is actually not you know, it is
being detected by the rule engine. The other thing is that your database comes with
them many many different functionalities that you may not need for your application. It
may be just a simple database lookup database storage, inserting rows are inserting,
updating rows or deleting rows etc. So in that case, any other functionality that is there
for more complex applications, database applications, you should get rid of them
because vulnerabilities in them may be exploited in SQL injection type of attacks, for
example, XP command, shell, extended stored procedure in MS SQL, it's once a Windows
command shell and pass a string to execute. Now, which can be useful, but it is, you
know, for some types of applications where you are trying to also execute additional
commands outside the database and get inputs from that before we continue with your
database, queries, etc. But even if your application doesn't require such sophisticated
advanced activities, then you can turn it off. So there are configurations to which you
can turn off certain features. And this feature should be turned off, which is one
necessary. So we'll just process spawned by x, XP command shell has the same security
privileges as the SQL Server service accounts if their service account this is SQL server
services running with a privileged account, then this convention will also be privileged
and which will mean that further you know possibilities of exploitation. So you have to
reduce the attack surface by turning off unnecessary features. So the sixth tip is that use
appropriate privileges and this is true for anything that you actually use. You know, don't
run anything with a privilege in with a high identity privilege unless you absolutely need
that. So if the database needs to run with a user regular user privilege, and only thing
you need to do is sometimes look up the database etc. Do not run it with the heightened
privilege. And certainly not with admin login privilege. And so using a limited access
account is far safer and can limit what the hacker can do. So here, you're not only
reducing the attack surface, we are also limiting the attackers ability because attackers
access privileges will be limited. So code behind a login page should only query the
database using an account limited only to the relevant credentials tables. So you don't
need to be system administrators to actually check for this some piece of data exists in
the in a particular table. So your permissions should be set to that. So this way, a breach
through this channel cannot be leveraged to compromise the entire database or maybe
the entire system. So so this is very important to mind. Basically, it's the principle of least
privilege in work, keep your secrets secret that is passwords greater numbers, these
things even if you put in a database, which will always be hashed or encrypted or
whatever is necessary. So that even if the database is breached, the possibility of you
know revealing the actual trait and number actual password etc, will be minimized.
Now, if somebody had a weak password and it is hash, given that hash can be broken by
a rainbow or dictionary attack, so So of course the users have to be aware of the
importance of strong passwords etc. But in case you actually do store passwords or
other important credentials in the database, keep it in encrypted hash or hash form
whatever. So So, so minimize to minimize that the data will actually be disabled even if
the database gets exfiltrated. Now, tip number eight is that do not divulge more
information than you need to. So when we are when when you make a query to the
database, sometimes the database sends us a error message. And sometimes these
return messages are pretty evil. And that might give you give the if enough of us the
attacker had an idea about what database you're using, what version it is, all kinds of
information. So therefore, you have got custom error messages for sending that to the
front end, the front end should not need do not need to know what model it is or what
error messages are used to even even if we need to know it needs to know it from the
application perspective. doesn't need to know it from the database perspective. So
always have these custom, remote only error messages that needs to go to the front
end, which does not reveal much information about the database versions, what
whatever stuff that will give them more information than necessary. Because sometimes
just being using such errors, the attackers might want to know whether you're using
MySQL which version or whether you're using a system because there is query queries
might have slight differences, you might know that there is certain types of potentials
etcetera. The ninth and 10 tips are continuously monitoring the monitoring the SQL
statements from the database connected applications. So, this can be done through the
log of the web application firewall or from the database itself. So you know that whether
your system is being subjected to SQL injection attempts, so there are monitoring tools
that can use machine learning and other behavioral analysis to actually monitor and
check whether because we have also done in our research, such machine learning
algorithms, which can determine whether there is some issue the request is attempted
SQL injection. And then finally, by better software, make code writers responsible for
checking the code and not for fixing security flaws in custom applications before the
software is delivered. So, by better software means by meant in this case by better web
application frameworks or by better, which has better centralization routines, etc. Also,
the database engine etc, there should be there should be less vulnerabilities because
application developers do not want to develop all the logic and functionality of the
application. Security's is also has to be done. But if he has to, you can, you can think of
securing its own application by making call to sanitization routines, etc. But if he has to
give out the SSL decryption routine, because it is flawed, then it is not his work, because
it's part of the framework. So therefore, the application designers should not be
burdened with fixing security vulnerabilities in the database or in the framework or
sanitization routines, etc. So better quality software was should be given to the
application developers so that he's responsibility of application design, security is about
is mitigated by, by making the calls to the routine that that that sanitizes, that produces,
escaped, escaped, escape string screens, etc. And those routines should not be flawed,
flawed themselves. So that's the point here. So these 10 tips are basically, you know,
doesn't make you a SQL injection proof application developer. It's actually, as I said, that
if you go to this release, do you see a lot of standard products have SQL injection, even
today, so So you have to always be on the lookout. And, you know, what we have shown
here is just the tip of the iceberg. It's practitioners who learn from writing web
applications, which has database backing, and then, you know, burning their hands, to
many, many mistakes. And then finally, getting better and better at writing SQL injection
to for command injection proof applications. What we learned here is some basic things
that you must do, and basic things. And eventually, it all, all boils down to the fact that
when you get some input from outside, before even making a script gradient before
sending it to, to system command, or, you know, passing it to a command shell for, you
know, executing a shell command, you must check the sanity programmatically, you're
not sitting there so you cannot manually check every all left stuff that is being passed to
the SQL inject SQL database for PSP, or whatever is being passed to the system
command or whatever is being passed to the to the command shell, etc. For the back
end by the back end program. So you obviously have to do this programmatically to
sanitization meetings and so on. Code Review of the application is very important
because you know, many times even and some like buffer overflow, right. So, you might
have forgotten to sanitize the input and send it to a routine which might have a buffer
overflow vulnerability. So, irrespective of whether the routine has buffer overflow
vulnerability, you should always check for sanity, you should always check the disk space
for storing the string and the size of the string have a feed right. So, similarly, here also
like you have to see that whenever some in user input is being passed on, to form
queries or to form commands, their sanity has to be has to be validated through some
routine. So code review will actually give will such omissions and mistakes. So so that is
very important to be coded. Anyway, so I think that is the end of this set of slides and,
and in the next video, I will do some demos on TBWA. And, and then we'll move on to
the other attacks such as excesses or CSRF attacks, as I said, that, in this post, we are not
going to actually do you know, extensive set of web application attacks, because this is
time is limited source is limited here. So, what we are doing is to make you aware of
some of the attacks very, very clearly, hopefully, but the others there you know, 10
different types of different types of attacks that are also possible on applications
depending on the application. And you from this knowledge that you are gaining from
here, it is expected that you will be able to, you know, freed up position to gain more
and more access and knowledge to the right set of literature like set of write up some
tips on medium.com There are other sites, many vendors sites, they have all these blogs,
in which they talk about attacks, some sometimes very rare types of vulnerabilities, but
you should be able to read and understand them if you know the basics of how the front
end of an application is sent to the browser. And the browser imposes say you know
same origin principle to actually make it protected from other applications since front
end is also running on the same browser. And how sometimes we require the
interaction between multiple regions and how this is done. And then going going back to
the application side, which is on the server, you know, what kind of mistakes the
applications might do in order to not sanitize inputs and not sanitize unfortunately, in
the especially in the context of access, that not sanitizing output also could be a
problem. So these are kind of basic in architecture of web application and how this
architecture works, how the protocol stateless protocol is converted to stateful protocol
with cookies, and how these cookies etc can be exploited. So this will give you an
overarching understanding of the web application security space. But again, and again, I
want to tell you that this is not exhaustive. And this does not make you a web
application security expert. So you have to continue to learn even after learning what we
are doing here. So that's a very important point to remember. All right, so we'll in the
next lecture video will show you some practicals and then we'll move on to the other
attacks.