[nycphp-talk] "The Web is broken and it's all your fault."
Anirudh Zala
arzala at gmail.com
Fri Sep 15 03:30:38 EDT 2006
Proper programming practices solves 90% of security related problem that
can occur at application level. However this "practice" is entirely
dependent on experience of developer. But below mentioned steps would
surely solve most of your problems.
1) The biggest area of this problem is browser. Not because that it is
being exploited in many ways but why can't browser itself provide basic
level of validation and input filtering like validations of name, email
address, phone, fax, mobile etc. according to country or region. This is
not big task or too much difficult for browser's and it's extension's
developers. If we have characters set encoding, to display text in various
languages, available in browser then why can't we have support of
validation of above items. Now it is not that big that which validation
format is to be used for each country or region. We can tell browser from
our HTML in similar way about which character set encoding to be used.
Our browsers are in still baby or old styled which doesn't help much as
far as security and input filtering related to forms are concerned. They
have evolved in terms of designs and layout (we all know how fast support
of various CSS format has grown) has but not in terms of programming.
Since this is not problem at an application area, it can not be solved at
that level.
2) We need to start think and use Web in terms of "Human" and not just as
machine. I am pointing towards Smart usage of our data rather than just
using as it is. For example while mentioning email address at public
place, user can write it in such a way that it can not be figured out from
sources of data. By this way 70% of spamming can be stopped because
spammer programs can not figure that out. See below examples:
a)
-----------------------------------------------
Anirudh Zala (Project Manager)
ASPL, http://www.aspl.in
arzala@@gmail.com
-----------------------------------------------
I have used 2 @s while mentioning my email address. (This is vulnerable
but not easy.)
b)
-----------------------------------------------
Anirudh Zala (Project Manager)
ASPL, http://www.aspl.in
FIRSTNAME at gmail.com
-----------------------------------------------
This would be interpreted as "Anirudh at gmail.com" instead of
"FIRSTNAME at gmail.com"
Following these kind of practices can fool most of automatic spamming
programs (because they search single "@" sign or " at " to grab email
addresses from sources) but not the person who is viewing it because
he/she knows that what it means. Even if they copy and paste above email
address to send email, email client will not allow to send email and they
will soon find problem area. One possible drawback of this approach at
application level could be handling of such email addresses while storage
and retrieval. But as far as just displaying is concerned, it is really
magical.
3) Security and filtering must follow certain order rather than
concentrating at 1 area only. Filtering divided at various levels
effectively reduce burden on developers and at the end on application. One
can follow below order to filter and store input data.
a) While designing database, if values of certain field is not going to
exceed than certain limit, let's say maximum 3 types then use "enum" as
field type rather than "varchar" or "*int" etc. By this way data that
falls outside the range of "enum" values will not be stored.
b) Most of application has 2 areas viz. Administrative and Client.
Administrative area needs almost full control over application's data
while Client area might not need. So such application should be run as 2
database users where 1st user will have higher privileges and more control
over data than 2nd. 2nd user can mostly have "select, update, insert and
delete" privileges on required tables only. So no other privileges should
be given to that user for rest of the tables which are used for
administrative purpose only.
c) Handle your errors properly. Instead of showing (knowingly or
unknowingly) them into browser log them in file and report developers via
email.
d) In most of applications (specially built using PHP), there is not any
file which requires "execution" permission, so discard that permission
fully for such files.
e) Keep files and folders outside web-root which are to be used internally
like includable files, raw templates etc.
f) While validation data in your application, do not just concentrate in
any 1 area like at SQL level etc., Instead filter/validate it at various
stages.
1st stage is JS which is most close to client so you can do most of
validation with that and can prompt client instantly to correct required
data.
Do not mind if JS is off. 2nd stage could be validating same things using
PHP. You can build powerful regular expressions for that. At this level
most of data can be validated and filtered. Care taken at this level will
make your application safe against most of attacks.
Most of time we know range and type of data which is being inserted. So we
can easily check them using regular expressions. Order of filtering data
should be GET, POST and COOKIE because exploitation level of these 3 types
are 3, 2, 1 (1 means lowest, 3 means highest). Now if you are not
satisfied with these, finally validate rest of data at SQL level (using
mysql_real_escape_string etc. and perhaps converting SQL breaker
characters, like ', ", ; etc., into HTML entities) before storing into
database.
I don't think that implementing these points is heavy or difficult task
for developers so that it needs extra time and money from client. In fact
security should be free with any application :)
Bottom-line: We all know that no application can be made 100% secure. But
we can surely try hard not let exploiters and attackers figure out that
where is the remaining % of area which is insecure.
-----------------------------------------------
Anirudh Zala (Project Manager)
ASPL, http://www.aspl.in
arzala@@gmail.com
-----------------------------------------------
On Thu, 14 Sep 2006 19:51:42 +0530, Peter Sawczynec <ps at pswebcode.com>
wrote:
> It would seem that it would be more optimally secure to both:
> i) correctly handle the data, but also to
> ii) check for what the data is.
>
> That would include checking length and data type. Wrong data types
> and too long strings can break SQL queries.
>
> But, hypothetically, if one is stuffing all their data into type VARCHAR
> fields
> all kinds of things will get handled. But, later data summary reports
> from
> the database can produce inaccurate results.
>
> I was just reviewing Adobe best practices on Flash ActionScript 2.0
> and they suggested that all variables be declared and be
> strongly typed to force your application to throw errors immediately
> when wrong data types get sent to a function.
>
> The ActionScript strong data typing is of the form:
> var cust_first_name : string
> var this_date : Date
>
> It appears that almost every other language competitively positioned to
> PHP
> forces discipline a bit more, starting with making one know the expected
> data type(s) at all junctures.
>
> Warmest regards,
> Peter Sawczynec,
> Technology Director
> PSWebcode
> _Design & Interface
> _Ecommerce
> _Database Management
> ps at pswebcode.com
> 646.316.3678
> www.pswebcode.com
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org]
> On
> Behalf Of Dan Cech
> Sent: Thursday, September 14, 2006 9:40 AM
> To: NYPHP Talk
> Subject: Re: [nycphp-talk] "The Web is broken and it's all your fault."
>
>
> michael wrote:
>> http://www.internetnews.com/dev-news/article.php/3631831
>> "
>> Those are the words that Rasmus Lerdorf, the creator of PHP,
>> said to kick off his keynote at the php|works conference under
>> way here.
>> ...
>> "The Web is pretty much broken, we can all go home now,"
>> Lerdorf said somewhat sarcastically to the capacity crowd.
>> "Luckily most people don't realize that it's broken."
>>
>> Part of the reason Lerdorf considers the Web "broken" is that
>> it is inherently insecure for a variety of reasons. One of those
>> reasons sits at the feet of developers.
>>
>> "You don't know that you have to filter user input," Lerdorf
>> exclaimed.
>> "
>
> Personally, I'm of the opinion that right now people tend to focus too
> much
> on input filtering, and not enough on safe storage and display practices.
>
> If you are correctly handling incoming data, it makes little difference
> what
> that data may be. For example, if you construct a query like:
>
> $query = "SELECT * FROM mytable WHERE myid='$someid'";
>
> You are obviously vulnerable to assorted SQL injection attacks.
>
> However, construct the query like:
>
> $query = 'SELECT * FROM mytable WHERE myid='.
> mysql_real_escape_string($someid);
>
> or:
>
> $query = 'SELECT * FROM mytable WHERE myid=?';
> $args = array(
> $someid,
> );
>
> And you have prevented the attack, regardless of the contents of $someid.
> This is because you are correctly formatting the data in context, in this
> case as an SQL string.
>
> The same goes for displaying data on a webpage, pass it through
> htmlspecialchars and you'll be guaranteed that it is correctly formatted
> as
> a block of HTML CDATA.
>
> The security breach comes from treating the data incorrectly, not from
> its
> contents.
>
> That said, if you need to display html received from the client as html,
> you
> need input filtering to separate the bad from the good. However, these
> cases are not the norm, and in many situations input filtering is merely
> restricting the data you're allowing clients to input, without any real
> security gains.
>
> If you need to enforce certain restrictions on user input, according to
> the
> 'rules' of the system then input filtering is a great idea, but don't get
> caught up in thinking that filtering input is the answer to all security
> problems.
>
> Dan
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
More information about the talk
mailing list