How to Protect Your Website from Hacking Attacks
SQL database-driven websites are at risk. , Any web page which passes parameters to a database can be vulnerable to attacks., Get a basic overview of hacking., Understand how hackers do it., Understand how to hack your own website.,Type your URL...
Step-by-Step Guide
-
Step 1: SQL database-driven websites are at risk.
This includes e-commerce shopping carts or any other website that has a form for login, search, etc.
Any SQL database-driven website is at risk of hackers who may be able to enter into the database through a back door.
Usually these back doors are present in URL query strings and form inputs, such as Login forms, Search forms, or other user input textboxes that can communicate with a database., Generally, a hacker can enter bogus characters into the URL querystring or a textbox.
The bogus input is then interpreted as SQL rather than ordinary user data and is executed by the unsuspecting database.
As a result, the website may break and display an error, allowing the hacker to glean private information about the database.
Even worse, the hacker's hazardous scripts may actually be executed on the database, causing security breaches and/or permanent damage. , The first goal of a hacker is to repeatedly try to break a website, causing it to display a variety of valuable errors that give away private database details.
In this way, he can gain insight into the structure of the database and ultimately create a map or footprint of all its tables and columns.
The second goal of the hacker is to actually manipulate the database by executing scripts in malicious ways.
With control over the database, the hacker may possibly steal credit card numbers, erase data or infect it with viruses, among other nasty things.
In essence, the URL querystring and textbox are the two back doors into a database.
Getting errors and manipulating the back doors are the two methods used by hackers to ultimately destroy a database. , Let's look at how a hacker might go about breaking into a website.
Using the first technique described, he can hack the URL querystring and cause an error to be displayed.
You can do a simple test to hack into your own website via the URL querystring.
All you have to do is type something else directly into the address bar at the end of your query string. ,,,,,,,,, After generating a series of these kinds of valuable errors, a hacker can piece together private database details which will ultimately help him break into and wreak havoc on the database.,, This way, a hacker will never see any detailed error messages.
If you do nothing else, this is the number one thing that every website must have.
Otherwise, you are giving the hacker an open invitation into your database and practically offering him all the information he needs to launch an attack.,, To setup your own custom error page, you will need to consult your web host for instructions.
Generally, you will create a new HTML page to look the way you please and that says something short and sweet, like 'Sorry, the page you have requested is unavailable.' Then save it as error404.htm and upload it to your server.
Following the instructions from your host, you will change the website settings to point to the new error page.
This will stop many hackers right in their tracks.,, In an effort to execute malicious scripts on a database, a variety of creative coding is employed, such as %20HAVING%201=1 or maybe %20;shutdown with no wait-- or much worse.
Once the hacker is able to execute scripts, the vulnerable database is like putty in their hands.
The hacker never has to know the database login or connection string because he is using the URL querystring which already has an open connection.,,,, A hacker may manipulate any textbox within an HTML form.
A search box or a login form with username and password fields are all prime targets.
The hacker can enter bogus characters into the textbox and submit the form.
The input is then interpreted as SQL rather than ordinary user data and executed by the database.
Again, this attack will either cause an error so he can glean private information about your database, or it may actually insert hazardous scripts and wreak havoc on the database.,,,, The number one way to block a hacker from manipulating the URL query string and textboxes is to block their input.
But, how do you determine who they are, what they will input and whether or not it is safe? Unfortunately, you cannot know.
So, you must assume that all user input could be potentially dangerous.
A common saying in the programming world is that ALL INPUT IS EVIL.
Thus, it must be treated with caution.
Everything from everybody should be checked every time to ensure dangerous code does not slip in.
This is accomplished by checking all input that is submitted via a querystring or form and then rejecting or removing unsafe characters before it ever reaches the database.
If this sounds like a lot of trouble, you are right.
But, it is the price we pay to protect our websites and databases from the wrath of hackers.
It is your responsibility as the webmaster to ensure that only clean, safe input is allowed to enter your database.,, In other words, using ASP code on a web page can validate the input collected from the querystring or form to make sure it contains only safe characters.
Once the input is deemed safe, it can be stored in a new variable, inserted into the SQL string and sent to the database.
For more details about validation,,, We want to thoroughly clean all input by first checking for safe characters and second by checking for bad strings.
See the resources at the end of this article for a more in depth discussion on this method.,,, Following is an ASP example that renders the single quote harmless, by replacing it with two single quotes.,,, Or, filter out characters such as the dollar sign $ quotation mark " semi-colon ; and apostrophe ' the left and right angle brackets <> the left and right parentheses ( ) the pound sign # and the ampersand &.
Or convert these characters to their HTML entities.,, Remember a hacker can easily save a copy of your webpage, then modify the HTML and javascript, then re-upload the page.
Therefore, it is best to never use javascript alone for input validation since it can easily be removed, and instead duplicate any java script validation with ASP validation.
Also, hidden input fields are a threat in the same way since they can easily be altered to include bogus code.
Other tips include:
Never give away any clues about your database, including making your input field names the same as the database field names.
Always set a max length for inputs and truncate the excess., Topics discussed include, password policies, buffer overrun, creative table and column names, table name aliases, set and check data types, .bak files, stored procedures with parameters, and log files. -
Step 2: Any web page which passes parameters to a database can be vulnerable to attacks.
-
Step 3: Get a basic overview of hacking.
-
Step 4: Understand how hackers do it.
-
Step 5: Understand how to hack your own website.
-
Step 6: Type your URL like the following example and press enter: http://www.mywebsite.com/bookreports.asp?reportID=21
-
Step 7: Now simply add a single quote to the end the query string and press enter: http://www.mywebsite.com/bookreports.asp?reportID=21'
-
Step 8: Generate an error.
-
Step 9: As predicted
-
Step 10: you may have successfully broken your website and received an error as follows.
-
Step 11: Error Type:
-
Step 12: Microsoft OLE DB Provider for ODBC Drivers (0x80040E14)
-
Step 13: Unclosed quotation mark before the character string ' AND users.userID=reports.reportsID'.
-
Step 14: /bookreports.asp
-
Step 15: line 20
-
Step 16: The single quote causes an unclosed quotation mark error and now the once-secret table names and column names of your database are publicly visible.
-
Step 17: Hide website errors.
-
Step 18: The top most effective solution for keeping the private details of your database from getting into the hands of a hacker is to setup a custom error page for your website.
-
Step 19: Setup custom error pages.
-
Step 20: Some hosting services automatically use custom error pages to help protect your security.
-
Step 21: Manipulate the URL querystring.
-
Step 22: Besides fishing for errors
-
Step 23: a hacker can enter even more dangerous code than a simple single quote into the URL querystring.
-
Step 24: http://www.mywebsite.com/bookreports.asp?reportID=21'; drop table myTablename--
-
Step 25: Your table is permanently deleted.
-
Step 26: Manipulate the form input.
-
Step 27: The other most common point of entry besides the URL querystring is the form input.
-
Step 28: Fred'; drop table myTablename--
-
Step 29: Your table is permanently deleted.
-
Step 30: Block input containing malicious code.
-
Step 31: By now
-
Step 32: you probably have a good idea of how much damage a hacker can do and you are ready and willing to do whatever it takes to stop them.
-
Step 33: Input validation.
-
Step 34: To check if the input entered into the URL querystring or textbox is safe
-
Step 35: we can use input validation rules.
-
Step 36: The wash and rinse cycle.
-
Step 37: Input validation should be a two-part process
-
Step 38: like a wash and rinse cycle.
-
Step 39: Filter characters.
-
Step 40: Another method that can be used in conjunction with the above two functions
-
Step 41: but is considered to be very weak when used alone
-
Step 42: is to sanitize the input by filtering or escaping.
-
Step 43: A well-known threat is the single quote or apostrophe because it breaks the SQL statement.
-
Step 44: 'double up single quotes
-
Step 45: new Safe String = replace(searchInput
-
Step 46: Other variations for the replace function include stripping out the script tag and replacing it with a space.
-
Step 47: Remember to use a solution that best fits your website or consult a professional.
-
Step 48: Finally
-
Step 49: there are a few other security measures that you can research and explore on your own.
-
Step 50: If you would like to pursue more advanced security techniques
-
Step 51: please see the resources at the end of this article.
Detailed Guide
This includes e-commerce shopping carts or any other website that has a form for login, search, etc.
Any SQL database-driven website is at risk of hackers who may be able to enter into the database through a back door.
Usually these back doors are present in URL query strings and form inputs, such as Login forms, Search forms, or other user input textboxes that can communicate with a database., Generally, a hacker can enter bogus characters into the URL querystring or a textbox.
The bogus input is then interpreted as SQL rather than ordinary user data and is executed by the unsuspecting database.
As a result, the website may break and display an error, allowing the hacker to glean private information about the database.
Even worse, the hacker's hazardous scripts may actually be executed on the database, causing security breaches and/or permanent damage. , The first goal of a hacker is to repeatedly try to break a website, causing it to display a variety of valuable errors that give away private database details.
In this way, he can gain insight into the structure of the database and ultimately create a map or footprint of all its tables and columns.
The second goal of the hacker is to actually manipulate the database by executing scripts in malicious ways.
With control over the database, the hacker may possibly steal credit card numbers, erase data or infect it with viruses, among other nasty things.
In essence, the URL querystring and textbox are the two back doors into a database.
Getting errors and manipulating the back doors are the two methods used by hackers to ultimately destroy a database. , Let's look at how a hacker might go about breaking into a website.
Using the first technique described, he can hack the URL querystring and cause an error to be displayed.
You can do a simple test to hack into your own website via the URL querystring.
All you have to do is type something else directly into the address bar at the end of your query string. ,,,,,,,,, After generating a series of these kinds of valuable errors, a hacker can piece together private database details which will ultimately help him break into and wreak havoc on the database.,, This way, a hacker will never see any detailed error messages.
If you do nothing else, this is the number one thing that every website must have.
Otherwise, you are giving the hacker an open invitation into your database and practically offering him all the information he needs to launch an attack.,, To setup your own custom error page, you will need to consult your web host for instructions.
Generally, you will create a new HTML page to look the way you please and that says something short and sweet, like 'Sorry, the page you have requested is unavailable.' Then save it as error404.htm and upload it to your server.
Following the instructions from your host, you will change the website settings to point to the new error page.
This will stop many hackers right in their tracks.,, In an effort to execute malicious scripts on a database, a variety of creative coding is employed, such as %20HAVING%201=1 or maybe %20;shutdown with no wait-- or much worse.
Once the hacker is able to execute scripts, the vulnerable database is like putty in their hands.
The hacker never has to know the database login or connection string because he is using the URL querystring which already has an open connection.,,,, A hacker may manipulate any textbox within an HTML form.
A search box or a login form with username and password fields are all prime targets.
The hacker can enter bogus characters into the textbox and submit the form.
The input is then interpreted as SQL rather than ordinary user data and executed by the database.
Again, this attack will either cause an error so he can glean private information about your database, or it may actually insert hazardous scripts and wreak havoc on the database.,,,, The number one way to block a hacker from manipulating the URL query string and textboxes is to block their input.
But, how do you determine who they are, what they will input and whether or not it is safe? Unfortunately, you cannot know.
So, you must assume that all user input could be potentially dangerous.
A common saying in the programming world is that ALL INPUT IS EVIL.
Thus, it must be treated with caution.
Everything from everybody should be checked every time to ensure dangerous code does not slip in.
This is accomplished by checking all input that is submitted via a querystring or form and then rejecting or removing unsafe characters before it ever reaches the database.
If this sounds like a lot of trouble, you are right.
But, it is the price we pay to protect our websites and databases from the wrath of hackers.
It is your responsibility as the webmaster to ensure that only clean, safe input is allowed to enter your database.,, In other words, using ASP code on a web page can validate the input collected from the querystring or form to make sure it contains only safe characters.
Once the input is deemed safe, it can be stored in a new variable, inserted into the SQL string and sent to the database.
For more details about validation,,, We want to thoroughly clean all input by first checking for safe characters and second by checking for bad strings.
See the resources at the end of this article for a more in depth discussion on this method.,,, Following is an ASP example that renders the single quote harmless, by replacing it with two single quotes.,,, Or, filter out characters such as the dollar sign $ quotation mark " semi-colon ; and apostrophe ' the left and right angle brackets <> the left and right parentheses ( ) the pound sign # and the ampersand &.
Or convert these characters to their HTML entities.,, Remember a hacker can easily save a copy of your webpage, then modify the HTML and javascript, then re-upload the page.
Therefore, it is best to never use javascript alone for input validation since it can easily be removed, and instead duplicate any java script validation with ASP validation.
Also, hidden input fields are a threat in the same way since they can easily be altered to include bogus code.
Other tips include:
Never give away any clues about your database, including making your input field names the same as the database field names.
Always set a max length for inputs and truncate the excess., Topics discussed include, password policies, buffer overrun, creative table and column names, table name aliases, set and check data types, .bak files, stored procedures with parameters, and log files.
About the Author
Nicole Castillo
Professional writer focused on creating easy-to-follow crafts tutorials.
Rate This Guide
How helpful was this guide? Click to rate: