|
In server issues 1 we considered the scenario where a malicious user had taken advantage of a server’s vulnerability to the “.htr” attack to type in the fllowing code to drop a database table off the server:
“.cfm?id=104;DROP%20TABLE%20MEMBERSINFO”
Creating the query:
<CFQUERY NAME=”membersdata” DATASOURCE=”Localserver”>
Select * FROM membersinfo
WHERE id = ‘url.id’
DROP TABLE MEMBERSINFO
</CFQUERY>
This is not good at all!
While your server may not be vulnerable to this particular form of atttack that does not mean a malicious user can not drop your tables. It is very easy to generate a script or program to keep generating random table names and use these to send http request to your server to try and crack the table name and bring it down.
Well the news is good there are several easy steps to protect against this form of attack.
don't reveal the name of the databases
Ensure that the server and your scripts do not reveal the names of the databases used by scripts in the debug information.
To find out if this is the case add the following to the end of one of your scripts: "?mode=debug".
EG myscriptname.cfm?mode=debug
Under most circumstances you will get some information about the script and it's execution. This can often be useful information during script development. However if you can see the names of any databases used by the script then so can any hackers - and they will know how to do this!
What to do if your database name is exposed by the debug:
The second thing you want to do is contact the server manager to amend the ColdFusion server settings so that Show SQL and data source name is unchecked.
The first thing you want to do is to amend all scripts that use databases (even better amend all scripts) so that they carry the following at the top of each script:
<CFSETTING ENABLECFOUTPUTONLY="No"
SHOWDEBUGOUTPUT="No">
This will prevent any usable information being given away by your scripts.
Even if your server is set accordingly it is good practice to use the above at the top of scripts, since server settings may be changed without notice.
don't allow unexpected requests to be processed
Okay we now have the first line of defence in place, although there is no room for complacency. While you are not giving away any information the patient database trasher has tools and time on their hands, after all your database access script is just sitting there on the server waiting to accept more attempts. So if the trasher has a little program or script of their own to generate random table names to throw at your script then it is only a matter of time before the script succumbs!
How do you protect against this?
Easy.
Handle all unexpected queries.
You should be doing this any way as good scripting practice.
Many scripts will provide databased information with something like...
myscriptname.cfm?id=234
...where the id number refers to a unique database identification number.
The easiest way to make sure a script like this is not abused is to check that the id value is a number. Use the function IsNumeric.
A way of using this is:
<CFSET inputok = 1>
<CFIF IsNumeric(url.id) IS FALSE>
<CFSET inputok = 0>
<CFELSE>
do database query here...
</CFIF>
... page layout and format...
<CFIF inputok = 1>
display databased information here...
<CFELSE>
display an error message here about incorrect URL
</CFIF>
The simple expedient of checking whether the value being passed to a script is of the correct form, in this case a number, and then only performing an action if it is correct will protect your database from harm.
|
