[thelist] Website Hacked?

Chris Anderson Chris at activeide.com
Wed May 28 19:38:04 CDT 2008


> do so (along with some better data cleansing).  I understand the use
of
> a
> parameter, but not quite sure how to implement it.  But I have some

That would obviously depend on language/platform being used. What are
you using again (in case I can help)?

> 	Query = "select this from that where id = " & id

Ouch, yeah - the basic injection target :-\

> I was checking to see that it was being passed an integer, but
> obviously
> that wasn't enough.  

Actually, it would have been okay - if you used the cleansed integer.
(i.e. the value of the string *after* it had been converted to an
integer)
For example, if you used Val(id) in ASP to see if that converts without
error, it will convert "300;INJECTED SQL" as 300.
If you then use id in the SQL it will append "300;INJECTED SQL".  If
however you did the following:
	cleanId = Val(id)
	Query = "select this from that where id =" & cleanId 
It would have been fine, because cleanId will only hold an integer 
(If using a type-safe language, converting the id to an integer variable
then using that would be even safer)


> The whitepaper that I was reading also mention that one of the ways an
> attacker figures out stuff is because bad attempts to hack may reveal
> database error messages from the server.  What is a common way to
avoid
> that?  I tried a few hacks that it mentions and I don't get anything
> "valuable".  So I don't know whether my site is or isn't vulnerable to
> that.

It depends on language/platform on *how* but the safest way is to aim to
handle all errors by showing the user a standard error page with NO
information on it (except general stuff like "An error occurred, and the
admin has been notified"). This page should be the same whatever the
error (you might even wish to use a basic HTML file). The details of the
error can be stored in logs (event logs, text files, etc) and/or emailed
to someone (you, admin, etc)

However - once you have verified the data as valid (an integer in the
above for example), then the only errors the user can cause are trying
to get records that do not exist, etc (setting id = -1000 for example)
or trying to force an out of range error (sending id=32768 will bomb if
using an integer rather than a long - but then your code to check it's a
valid Integer should return false and catch it anyway).
Handle those cases and they cannot do anything (in the above case)

Chris







More information about the thelist mailing list