<br><br><div><span class="gmail_quote">On 6/7/06, </span><span style="font-weight: bold;">Chris Palmer</span><span class="gmail_quote"> <</span><a href="mailto:chris@eff.org">chris@eff.org</a><span class="gmail_quote">> wrote:
</span><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Think of it like this: You are putting data into MySQL and you decide<br>
> to name your variable $query. Let's say someone tries to be smart and<br>> recodes your form and makes a field called "$query". They just<br>> injected your database.<br><br>Oh, you don't need register_globals on for SQL injection to be all too
<br>easy. Watch the Bugtraq mailing list for, like, 20 seconds, and you will<br>see 20 posts about PHP apps with SQL injection vulnerabilities. Every<br>unvalidated input variable that later is used as part of an SQL query is
<br>an SQL injection vector. It's part of the fun!<br></blockquote></div><br>What I don't understand is, since everyone knows SQL injections are a problem, why isn't there a standard function that will clean up any user submitted data before performing SQL operations? Or, perhaps there could be a default setting that would just automagically screen for attacks.
<br><br>This security-as-an-afterthought method of designing languages/platforms is really hurting our ability to develop new and innovative applications. If I'm spending half my time worrying about script-kiddies, I don't have as much opportunity to invent a useful feature or write comprehensive documentation or do usability testing.
<br><br>Anyone agree?<br><br>--<br>Suzanne Aldrich <br><a href="mailto:aigeanta@gmail.com">aigeanta@gmail.com</a>