Re: [PHP] Filtering data not with mysql...
Hi Richard, Oh my... I hate those pdf's :-(( Could someone tell me in some words what do I need to do beside mysql_real_escape_string() and Html input sanitizing? Thanks and sorry for the inconvenience) -- With best regards from Ukraine, Andre Skype: Francophile My blog: http://oire.org/menelion (mostly in Russian) Twitter: http://twitter.com/m_elensule Facebook: http://facebook.com/menelion Original message From: ad...@buskirkgraphics.com ad...@buskirkgraphics.com To: 'Jason Pruim' Date created: , 4:17:55 AM Subject: [PHP] Filtering data not with mysql... To quote Jonathan Well, mysql_real_escape_string doesn't protect against sql injections more than addslashes, but that's not the reason you use it. addslashes() was from the developers of PHP whereas mysql_real_escape_string uses the underlying MySQL C++ API (i.e. from the developers of MySQL). mysql_real_escape_string escapes EOF chars, quotes, backslashes, carriage returns, nulls, and line feeds. There is also the charset aspect. However, it is a common thought among a lot of PHP programmers (beginning and even more advanced) that SQL injections are the only thing to guard against with sanitizing user input using it in a query. That, actually, is incorrect. If you only rely on *_escape_string and addslashes because you are only thinking about injections, you leave yourself vulnerable to attacks from users. http://dev.mysql.com/tech-resources/articles/guide-to-php-security-ch3.pdf It's a nice read, especially if you like reading articles about PHP programming (*guilty*). Scroll down to page 78 where they talk about LIKE attacks. Richard L. Buskirk -Original Message- From: Jason Pruim [mailto:li...@pruimphotography.com] Sent: Wednesday, May 18, 2011 9:19 PM To: php-general@lists.php.net Subject: [PHP] Filtering data not with mysql... Hey Everyone, Probably a simple question but I wanted to make sure I was right before I got to far ahead of my self I have a form that I am working on and this form will be emailed to the recipient for processing (Not stored in a database). When I store in a database, I simply run all the data through mysql_real_escape_string() and it's all good... Without the database, is it just as easy as addslashes($var)? or is there more that needs to be done? In the end, the info will be echoed back out to the user to be viewed but not edited and emailed to someone to add the registration collect money, etc etc. Am I on the right track or do I need to rethink my whole process? :) Thanks Everyone! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Filtering data not with mysql...
Andre,
I remember this exact question and I thought jonathan gave the best
answer.
He suggested the addcslashes function in combination with the
mysql_real_escape_string.
http://php.net/manual/en/function.addcslashes.php
This is a good read and the function was updated as recent as 5.2.5.
Please pay close attention to the name it is a C-like function not the normal
addslashes.
$sub = addcslashes(mysql_real_escape_string(%something_), %_);
He goes on to explain that mysql_real_escape_string and addslashes do NOT
protect against this next example.
$sub = mysql_real_escape_string(%something); // still %something
mysql_query(SELECT * FROM messages WHERE subject LIKE '{$sub}%');
And recommends the following.
$sub = addcslashes(mysql_real_escape_string(%something_), %_);
// $sub == \%something\_
mysql_query(SELECT * FROM messages WHERE subject LIKE '{$sub}%');
I understand you are not going to insert into a database at this time.
But you did state you are going to email the contents and I would take the same
precautions with user input fields.
Only a suggestion I hope this helps.
Richard L. Buskirk
-Original Message-
From: Andre Polykanine [mailto:an...@oire.org]
Sent: Thursday, May 19, 2011 7:38 AM
To: ad...@buskirkgraphics.com
Cc: 'Jason Pruim'; php-general@lists.php.net
Subject: Re: [PHP] Filtering data not with mysql...
Hi Richard,
Oh my... I hate those pdf's :-((
Could someone tell me in some words what do I need to do beside
mysql_real_escape_string() and Html input sanitizing?
Thanks and sorry for the inconvenience)
--
With best regards from Ukraine,
Andre
Skype: Francophile
My blog: http://oire.org/menelion (mostly in Russian)
Twitter: http://twitter.com/m_elensule
Facebook: http://facebook.com/menelion
Original message
From: ad...@buskirkgraphics.com ad...@buskirkgraphics.com
To: 'Jason Pruim'
Date created: , 4:17:55 AM
Subject: [PHP] Filtering data not with mysql...
To quote Jonathan
Well, mysql_real_escape_string doesn't protect against sql injections more
than addslashes, but that's not the reason you use it. addslashes() was from
the developers of PHP whereas mysql_real_escape_string uses the underlying
MySQL C++ API (i.e. from the developers of MySQL). mysql_real_escape_string
escapes EOF chars, quotes, backslashes, carriage returns, nulls, and line
feeds. There is also the charset aspect.
However, it is a common thought among a lot of PHP programmers (beginning
and even more advanced) that SQL injections are the only thing to guard
against with sanitizing user input using it in a query. That, actually, is
incorrect. If you only rely on *_escape_string and addslashes because you
are only thinking about injections, you leave yourself vulnerable to attacks
from users.
http://dev.mysql.com/tech-resources/articles/guide-to-php-security-ch3.pdf
It's a nice read, especially if you like reading articles about PHP
programming (*guilty*). Scroll down to page 78 where they talk about LIKE
attacks.
Richard L. Buskirk
-Original Message-
From: Jason Pruim [mailto:li...@pruimphotography.com]
Sent: Wednesday, May 18, 2011 9:19 PM
To: php-general@lists.php.net
Subject: [PHP] Filtering data not with mysql...
Hey Everyone,
Probably a simple question but I wanted to make sure I was right
before I got to far ahead of my self
I have a form that I am working on and this form will be emailed to
the recipient for processing (Not stored in a database).
When I store in a database, I simply run all the data through
mysql_real_escape_string() and it's all good... Without the database,
is it just as easy as addslashes($var)? or is there more that needs to
be done?
In the end, the info will be echoed back out to the user to be viewed
but not edited and emailed to someone to add the registration collect
money, etc etc.
Am I on the right track or do I need to rethink my whole process? :)
Thanks Everyone!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Filtering data not with mysql...
At 2:38 PM +0300 5/19/11, Andre Polykanine wrote: Oh my... I hate those pdf's :-(( Could someone tell me in some words what do I need to do beside mysql_real_escape_string() and Html input sanitizing? Thanks and sorry for the inconvenience) Hi: Here is part of what I wrote for my PHP class -- perhaps it will help: There are two simple rules in handling data: Rule Number 1 is to filter input. What that means specifically is to make certain that the user input is EXACTLY what you expect. You can filter, scrub, inspect, compare, or replace whatever comes in with what you expect. You need to be aware of what can come from a user and be able to deal with that data safely. Rule Number 2 is to escape output. What that means specifically is to transform any given chunk of data to a format that is suitable for the output medium. For example, ANY output headed to the browser should have htmlentities () preformed on it. If the data is headed to a database, it should have a database-specific function called, such as mysql_real_escape_string(). If the data is going to be included within an URL (i.e., GET parameter), it needs to pass through the urlencode() function. If the data is headed to XML it should have some kind of XML function called to wrap it in a CDATA or a pre-defined data format. If the data is headed out to JavaScript, then you need json (i.e., json_encode, json_decode, and json_last_error). So, you really just have TWO considerations: Filter input; Escape output It matters because Evil People do exist, and they WILL find a way to cause damage to you, and even to others, if you fail to protect your data and code. Common hacks include executing SQL to damage databases, or adding JavaScript to deface web-sites or even adding JavaScript to use YOUR web-site in an attack upon another website. Here is a good starting point for some of the details of what to do and why: http://phpsec.org/ HTH's tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Filtering data not with mysql...
For input sanitizing, and this will be helpful to anyone who writes code, listen to dan kaminsky's keynote at The Next Hope. He did a very good job at explaining the landscape of web programming and the essence of SQL injection and XSS, as well as proposed pretty neat ways to fix these. If you are writing the app from scratch, to prevent SQL injection, use Mysqli + prepared statements... or implement the base64 hack, or i am working on a library to simplify and secure mysql in php for some of my work, though it's got a few implementation quirks it does fail by default, it does not allow you to insecurely interpolate, and it does use prepared statements for everything, i am sharing it with anyone who wants to look at it... Anyways, here's a direct link: http://c2047862.cdn.cloudfiles.rackspacecloud.com/Friday%20Keynote%20-%20Dan%20Kaminsky.mp3 Enjoy, Alex -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray On Wed, May 18, 2011 at 9:18 PM, Jason Pruim li...@pruimphotography.comwrote: Hey Everyone, Probably a simple question but I wanted to make sure I was right before I got to far ahead of my self I have a form that I am working on and this form will be emailed to the recipient for processing (Not stored in a database). When I store in a database, I simply run all the data through mysql_real_escape_string() and it's all good... Without the database, is it just as easy as addslashes($var)? or is there more that needs to be done? In the end, the info will be echoed back out to the user to be viewed but not edited and emailed to someone to add the registration collect money, etc etc. Am I on the right track or do I need to rethink my whole process? :) Thanks Everyone! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Filtering data not with mysql...
To quote Jonathan Well, mysql_real_escape_string doesn't protect against sql injections more than addslashes, but that's not the reason you use it. addslashes() was from the developers of PHP whereas mysql_real_escape_string uses the underlying MySQL C++ API (i.e. from the developers of MySQL). mysql_real_escape_string escapes EOF chars, quotes, backslashes, carriage returns, nulls, and line feeds. There is also the charset aspect. However, it is a common thought among a lot of PHP programmers (beginning and even more advanced) that SQL injections are the only thing to guard against with sanitizing user input using it in a query. That, actually, is incorrect. If you only rely on *_escape_string and addslashes because you are only thinking about injections, you leave yourself vulnerable to attacks from users. http://dev.mysql.com/tech-resources/articles/guide-to-php-security-ch3.pdf It's a nice read, especially if you like reading articles about PHP programming (*guilty*). Scroll down to page 78 where they talk about LIKE attacks. Richard L. Buskirk -Original Message- From: Jason Pruim [mailto:li...@pruimphotography.com] Sent: Wednesday, May 18, 2011 9:19 PM To: php-general@lists.php.net Subject: [PHP] Filtering data not with mysql... Hey Everyone, Probably a simple question but I wanted to make sure I was right before I got to far ahead of my self I have a form that I am working on and this form will be emailed to the recipient for processing (Not stored in a database). When I store in a database, I simply run all the data through mysql_real_escape_string() and it's all good... Without the database, is it just as easy as addslashes($var)? or is there more that needs to be done? In the end, the info will be echoed back out to the user to be viewed but not edited and emailed to someone to add the registration collect money, etc etc. Am I on the right track or do I need to rethink my whole process? :) Thanks Everyone! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Filtering data not with mysql...
On Wed, May 18, 2011 at 9:18 PM, Jason Pruim li...@pruimphotography.comwrote: Hey Everyone, Probably a simple question but I wanted to make sure I was right before I got to far ahead of my self I have a form that I am working on and this form will be emailed to the recipient for processing (Not stored in a database). When I store in a database, I simply run all the data through mysql_real_escape_string() and it's all good... Without the database, is it just as easy as addslashes($var)? or is there more that needs to be done? In the end, the info will be echoed back out to the user to be viewed but not edited and emailed to someone to add the registration collect money, etc etc. Am I on the right track or do I need to rethink my whole process? :) Security depends on keeping a keen eye on context. You want to always be sure that your PHP scripts appropriately validate input according to the context (what cultures or languages are you expecting, what character encodings, etc.), and you want to escape output according to context. There are of course many other security issues developers have to watch for, but these two areas are the source of many of the security issues in web apps, and it sounds like you're looking for feedback specific to these two concerns. In this case it sounds like you'll be outputting user data using HTML, so the data should be properly escaped for HTML (also focused on context, as the output can be within a tag, an attribute of a tag, or a url of a tag, and each situation requires specific escaping.) Additionally, it sounds like you'll be using the user data in an email, so you'll have to properly escape the output to avoid email injection. To deal with the input validation and HTML escaping, I use my framework, Nephtali, but many other frameworks help you achieve this (including facebooks' XHP, which is quite clever according to context: http://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919), and the combination of PHP filters and functions like htmlspecialchars(), urlencode, etc., greatly facilitate rolling your own library if you wish. To prevent email injection, I use the Zend Framework Email classes, as they're very powerful, easy to use, and protect against injection. I'm a security expert by any means, as I've made mistakes in the past that have provided education the hard way! In fact, I'll confess that there was a point a few years ago that I'd sent Rasmus Lerdorf a link to promote my framework (back when it was OOP-based rather than the functionally inspired, which was a long time ago), and I thought I'd make a few quick edits just to make it easy for him to view the source and see how I was handling what I thought was a cool little parallel processing idea (it really wasn't that cool, I was young and dumb, and the implementation was slow.) In my haste to add the code, I actually worked outside of the framework's natural encoding capabilities, and I forgot to manually handle the validation and encoding (the feature was new enough that I hadn't yet integrated into the natural flow of processing.) Alas, because I noted the security focus of the framework, Rasmus ran some security tests on my site (which performed slowly because of my stupid parallel idea) and that code that I forgot to manually handle lead to the reply below: Given this claim and the fact that you are eating your own dogfood, as you say, then it is probably a bad sign that you have an XSS on framework site. The site is so slow it is hard to poke it for others, but there is an obvious one in the !--current_url=-- html comment. You are not escaping the url correctly there. It's been said before, but let me say it with meaning: NOW THAT'S EMBARRASSING! I tried to make a quick little edit, and even though I'd built a framework that focused on proper validation and escaping, I still forgot to add the validation and escaping code for one little snippet I told myself I'd get back to later to manually handle. *Moral:* Don't rush. Carefully deliberate on the context, both in terms of the expectations for input AND the nature of output. If you do this, you eventually will get the level of security you're after (that, and fuzz the heck out of something before you send it to Rasmus :) Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] Filtering data not with mysql...
On Wed, May 18, 2011 at 10:46 PM, Adam Richardson simples...@gmail.comwrote: I'm a security expert by any means, as I've made mistakes in the past that have provided education the hard way! Just to be very clear, this is a mistake (as the rest of the sentence implies), and it should have said: I'm *not* a security expert by any means, as I've made mistakes in the past that have provided education the hard way! Just another lesson on rushing :) Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
