On 13/02/2012 22:09, Haluk Karamete wrote:
> you've mentioned that the user would have had access to the sysobjects
No, there's a difference. *If* they had access to sysobjects then it
could've caused issues.
Ideally, you should have some level of segregation within your database.
That is, the user that is querying the database from the website doesn't
have access (read/write) to sysobjects as this isn't required.
To clarify - the credentials that are used on your website should only
have the minimum level of access: If these details are for any reason
compromised, then, should the person with those credentials get access
to the back end, they'll only be able to see the information that they'd
be able to on the website (albeit in a raw format). If they can see more
than that, then the potential for damage increases significantly.
Consider that you run your website with the root user credentials. These
are compromised. The person with these now has your root user details
and, as a result, makes a concerted effort to find a way in to your back
end. Having successfully done this, they can then drop the database.
> Let's assume he did. The page that this attempt occurred is hard-wired
> to display a single record in detail view. In the code, I have a bunch
> of echo $row-<title kind of statements...
You could always escape these. Some SQL injection attacks do account for
this kind of thing. They're typically much more sophisticated than the
one you quoted.
> I'm even more curious now; what kind of goodies this evil user would
> have gotten with having access to the sysobjects from the query
The family silver? Sysobjects contains pretty much everything about your
database - information about tables, views, stored procedures. Consider
it as something like a blueprint of your database.
> I mean how would my page display sysobjects data when I don't
> have anything to do with echo sysobjects stuff?
It wouldn't be inconceivable to escape out of what you've done to
protect yourself. I assume that if you're passing any input to the
database that it's already escaped?
> can you shed some light maybe?
Hopefully that helps.