|
|
Posted by shimmyshack on 06/28/07 22:16
On Jun 28, 10:28 pm, jb <jbri...@gmail.com> wrote:
> Hi all, ive been tasked with reviewing a php app for sql injection
> vulnerabilities left behind by another developer. I'm not a php
> developer by trade, but ive tinkered with php, and I have a firm
> handle on what sql injection is in the context of other platforms.
> Ive seen various methods of prevention recommended, and unfortunately
> for me, our former developer appears to have used all of them in
> various parts of the app. Some use mysql_escape_string, some use
> myql_real_escape_string , some use a quote_smart function which checks
> the magic quotes setting and uses addslashes appropriately.
>
> But one has me a little confused, and i'm not sure if it is a valid
> method for blocking sql injection.
>
> where username = \"" . $_COOKIE["user"] . "\"";
>
> does wrapping the string in double quotes somehow tell mysql to treat
> the contents within as literal? Thus making it sql injection safe?
just use myql_real_escape_string throughout. Things that check things
and "degrade" gracefully are no good. You are using a modern install I
hope, so just use the latest and best. If the latest and best is not
there, then implement the functionality dont degrade.
other security might include
what kind of sql inject are possible, + signs for instance might bring
back all the data, is the way the master-detail paging open to pulling
much data.
are you on security mailing list, how do you know if someone is blind
injecting your db, when are you notified of what types of events, how
do you log queries, what myswl system variable can you control for
security..
Do you use limit clauses, and make sure that the query cant just be
altered with text which is fine but would reveal more than yuo wish. -
thinking here of a statement in the url/post that is along the lines
of table=this&sql=select+rows+from+here+where+this=that that can be
played with
does your mysql user for the site run as a limited user, with rights
only for select etc.. that it needs for tables it needs on the db it
needs access to?
do you share a login table with another app, etc... (cookies
thransfered/credentials transfered from a demo across to the paid for
content)
does the cron job have the password in it?
are the passwords in the table stored as hashes, or "for convenience"
are they stored in plain text.
is that rss feed we just got up and running capable of returning paid
for content...
how does the system authenticate users, what kind of select and bounds
checking.
do you use whitelisting or blacklisting, predictable urls.
and many other types of thought that might be worth looking at, other
than the usual sanitisation.
Navigation:
[Reply to this message]
|