<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Chris,<br>
<br>
Thanks for your post and i take on board your comments about
security, however I need to clarify a couple of things :<br>
<br>
1) The entire database consists of 750 property address records,
growing at about 10 records per month, none of which is personal
information, none of which is mission critical,<br>
and all of which i enter myself directly thru phpmyadmin. In the
very unlikely case of db corruption by sql injection, it could be
replaced with minimal downtime.<br>
The database is simply a list of housing stock, whether it is
available or not and when it was inspected and who by, and users
have absolutely no opportunity<br>
to enter write ANY data to the database (apart from in a remarks
column which IS escaped) - all other interaction with the database
is by radio buttons, timestamps being entered<br>
into fields automatically etc. The only real data being recorded
is who visited where and when, and what the found - 99% by
dropdown lists.<br>
<br>
In the 'postcode void' case quoted <br>
a) The user has a list of properties of interest, he can select
one to view the details of via a hyperlink and at the bottom of
the record he is presented with a list of properties<br>
with a similar postcode - he hasn't had an opportunity to enter
the postcode variable - the select is done from the postcode of
the first record.<br>
<br>
On that page all he can do is check boxes , and enter his one set
of (escaped) remarks, then use the list of nearby properties to go
and look at.<br>
In fact the main point of this page is that the user scans a QR
code which takes him directly to the record, the table at the
bottom showing the nearby<br>
addresses means that he could in principle never even see the
postcode variable in that search should I decide not to display
it.<br>
So sql injection impossible via this variable. <br>
<br>
<br>
2) That said, this is only a proof of concept management
information trial - if it falls over or gets corrupted it doesn't
matter - all that is useful is to<br>
see whether the functionality is what the users wants, as more
uses for it become apparent I throw in a few more checkboxes, or
useful information to<br>
display.<br>
If it ever gets to the point where it needs to be released into
the wild, I would give a proper programmer a brief to start from
scratch <br>
but make it look and work 'just like this'.<br>
<br>
So for where I'm at with my coding ability I think 'it will do,
security' - eg user login in, user change tracking and minimal
user data entry choices, is<br>
enough to be going on with , there doesn't seem to be spending
hours escaping things when I can't even get my search to work.<br>
<br>
<br>
Regards<br>
<br>
Wayne <br>
<br>
<br>
<br>
On 15/07/2013 23:56, Chris Ellis wrote:<br>
</div>
<blockquote
cite="mid:CAF0QPmiQFC=dx=nrZMF3_QGdUnnVBHxkZxkaZwA3nwUF_YcrVw@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Wayne<br>
<div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I'm deeply concerned by your poor
attitude to security, there is no excuse for building
applications which are vulnerable to both SQL Injection and
Cross-Site Scripting vulnerabilities like your code sample
is. Remember, that under the Data Protection Act, a
business has a responsibility to look after the data it is
storing.<br>
<br>
</div>
<div class="gmail_extra">Using the code sample in a production
system, in my view is being professionally negligent. Esd
pecially given community members have pointed out the
issues.<br>
<br>
</div>
<div class="gmail_extra">
In general terms, whenever data traverses a trust boundary
it must be validated. For web applications, data must be
validated for every single request. You cannot use a
request parameter without first validating it. Never trust
your users, they might not act maliciously, but they will
act foolishly, never trust data they input.<br>
<br>
</div>
<div class="gmail_extra">1) You should never concatenate data
into SQL queries without escaping it, its one function
call. Preferably use prepared statements.<br>
<br>
$queryz = "SELECT * FROM property WHERE postcode like
'%$postcodevoid%' and let = '1'";<br>
<br>
</div>
<div class="gmail_extra">If $postcodevoid where to be
something like: <br>
<br>
'; DROP TABLE property; --<br>
</div>
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">Your going to have a bad day.<br>
<br>
<br>
</div>
<div class="gmail_extra">2) You should never output data in
HTML without HTML escaping it.<br>
<br>
print("<TD width=10% wrap style=\"wrap: 1 solid
#800000\">".$rowz["address1"]. " </td> ". " ");<br>
<br>
</div>
<div class="gmail_extra">If $rowz["address1"] where to be
something like:<br>
<br>
</div>
<div class="gmail_extra"> <script>window.location='<a
moz-do-not-send="true" href="http://mybadsite.com/">http://mybadsite.com/</a>'</script><br>
<br>
</div>
<div class="gmail_extra">Your going to have a bad day.<br>
</div>
<div class="gmail_extra"><br>
<br>
</div>
<div class="gmail_extra">I'll leave you with: <a
moz-do-not-send="true" href="http://xkcd.com/327/">http://xkcd.com/327/</a><br>
</div>
<div class="gmail_extra"><br>
<br>
</div>
<div class="gmail_extra">Regards,<br>
</div>
<div class="gmail_extra">Chris Ellis<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Wolves LUG mailing list
Homepage: <a class="moz-txt-link-freetext" href="http://www.wolveslug.org.uk/">http://www.wolveslug.org.uk/</a>
Mailing list: <a class="moz-txt-link-abbreviated" href="mailto:Wolves@mailman.lug.org.uk">Wolves@mailman.lug.org.uk</a>
Mailing list home: <a class="moz-txt-link-freetext" href="https://mailman.lug.org.uk/mailman/listinfo/wolves">https://mailman.lug.org.uk/mailman/listinfo/wolves</a></pre>
</blockquote>
<br>
</body>
</html>