|
|
Posted by Chris Shiflett on 09/21/05 20:16
bruce wrote:
> i've been searching/researching the areas of security regarding url
> input, form input, as well as database input (mysql). while there
> are plenty of articles that touch on the topic, i'm looking for a
> given site/package/lib (open source) that is pretty much the
> standard that i could use for my website/app...
The standard for what?
> basically, i don't want to recreate the wheel, if there is already
> a serious/good solution to this area. given the importance of this
> area, i'm assuming that there is a lib/package that already exists
> to handle these issues.
>
> i've looked through google, as well as various open source web apps
> to see how some of this is handled, and it appears the level of
> sophistication for handling this is all over the place!!
>
> i want to stress, i'm looking for the package/lib that's strong
> enough/valid enough to be used in a serious commercial app.. a lot
> of what i've seen/suggestions on various sites arent' complete/strong..
>
> (this stuff has got to be around/available, i mean google/ebay/1000's
> of sites are up/running without having issues!!!)
It looks like you give details below. Just to offer a friendly
suggestion, you want less (almost none) of the stuff above and more of
the stuff below if you want more people to read your email. I'm
surprised I made it this far. :-)
> -Should Handle basic regex filtering of POST/GET/REQUEST
There is a new input filtering extension in the works. However, it's
important to realize that filtering is very application-specific. While
many applications accept the same types of data (names, credit card
numbers, addresses, etc.), there is almost always something unique or
uncommon. No matter how easy the new filtering extension makes this
process, you're still going to have to do some work.
> -Filtering of basic mysql commands/functions/characters
> (Insert/Drop/etc...)
I can't understand what you mean by this, but it sounds like a bad idea.
If you inspect input and consider anything with an SQL keyword in it to
be invalid, you have some problems with your filtering:
1. With a blacklist approach, there is an increased risk of missing
something, thereby creating a vulnerability.
2. Legitimate data may contain an SQL keyword.
3. Relying on this suggests that you're mishandling data when you create
SQL statements. Otherwise, it shouldn't be a concern.
> -Should filter the arrays (GET/POST/REQUEST)
See above.
> -Filtering of basic mysql commands/functions/characters
> (Insert/Drop/etc...)
....
> -Check for datatype
Everything in $_GET and $_POST is a string.
> -Set Datatype
Set it to what?
> -Parsing/inspection of all data prior to insertion in sql_query_string
Assuming your data is filtered, you just need to escape it. Most
databases have a simple function call for this, and addslashes() works
for most of the ones that don't.
Better yet, use bound parameters or placeholders, which are available in
PDO, many database abstraction libraries, and some database clients.
> -Use of 'datatype' arg in the query to insure that the correct datatype
> val is used in the sql_string
This could be useful in the sense of not trying to insert a string into
an integer field, but each column already has a type defined in the
database. If you filter your data, which you should, this isn't an issue.
> -Regex comparison of the vals prior to use in the sql_string
How is this different from the last few times you've mentioned
filtering? I'm a big fan of Defense in Depth, but not to the point of
inspecting my data several times before I use it.
> -Proper usage of slashes/quotations around variables/sql_strings
If this is a problem for you, just use a database abstraction layer or PDO.
It sounds like almost all of your needs can be reduced to filtering
input and escaping output. If you take a step back and think of your
needs in terms of tracking data through your application, I think you'll
see that your needs aren't as complex as they might have seemed.
If your question is whether there are good open source projects that
adhere to all of these best practices, then the answer is yes, but I
agree that it's often difficult to distinguish between them if you're
not sure what to look for.
If you're just looking for a secure CMS (which I doubt, because I think
your email would have been one line), then I don't have any good
suggestions.
Hope that helps.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
Navigation:
[Reply to this message]
|