NYCPHP Meetup

NYPHP.org

[nycphp-talk] Injection Attack, any ideas?

tedd tedd at sperling.com
Mon Nov 19 16:51:14 EST 2007


At 1:25 PM -0500 11/12/07, Dan Cech wrote:
>tedd wrote:
>  > Scrub and clean all user input.
>>
>>  My understanding -- nothing can get in unless you allow it (barring
>>  server breaches).
>>
>>  Here's an example of js injection:
>>
>>  http://webbytedd.com/bb/insecure-form/
>>
>>  SQL injection (as I understand it) is simply allowing the user to
>>  prepare (in part) the SQL query. Scrub and clean user input and prepare
>>  the query yourself as per what you will allow.
>
>With all due respect, this is bad advice.  The decision to allow or
>disallow certain content is a business/application decision, not a
>security decision.

Above I said "Scrub and clean all user input" <-- that's not a 
business/application decision but rather one of security.

I don't care what the client says with regard to his business needs, 
I will not knowingly introduce any security breaches. Instead, I will 
try to produce what the client wants rather than what he says he 
wants -- surely he doesn't want a security breach.

>If you display content properly *as content* then it does not matter
>what it is.  The security problem here is NOT the data, it is the fact
>that the data is being displayed *as code*, in this case html code.

Negative. It's not "displaying the content" that's at issue but 
rather allowing foreign code to be injected into a MySQL query. You 
simply clean all user input. You never trust the user to do what's 
right with regard to any aspect of security. You control it all or 
you have no control.

>The fact that your example demonstrates the proper approach (using html
>escaping to display the user data) rather than 'scrubbing and cleaning'
>the input makes this advice even more confusing.

Well, I guess that we are both confusing, because I don't get what you said.

I am simply, but apparently not effectively, saying that you never 
trust outside data regardless. You never allow the user to have 
access to any portion of your code for injection -- period.

My example shows that a user could inject a piece of code and produce 
something that was not in my code. But, perhaps my demo is less than 
optimal in showing that -- sorry.

Cheers,

tedd


-- 
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com



More information about the talk mailing list