Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 25/04/07, Richard Lynch [EMAIL PROTECTED] wrote: On Mon, April 23, 2007 9:48 am, WeberSites LTD wrote: I'm trying to understand from the examples why anyone that has get_magic_quotes_gpc() returning true would need to use stripslashes() and then mysql_real_escape_string(). wouldn't that just add slashes to the same places? If you were 100% sure that everybody on the planet spoke only English, and only used the ASCII codeset, sure, it's the same thing... Oh, wait. Earth has more than one language, doesn't it? :-) mysql_real_escape_string() takes into account the charset[s] being used. addslashes assumes ASCII charset. Don't do that. YOU may not be expecting the Spanish Inquisition, but somebody will be trying to send it to you. Actually, over half the site visitors are _not_ going to be speaking English. Everything on the site is in UTF-8 as Israelis speak Hebrew, Arabic, Russian, Romanian, and another small language called English. Dotan Cohen http://what-is-what.com/what_is/zero_day_exploit.html http://dotancohen.com/eng/thunderstang.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote: On 25/04/07, Justin Frim [EMAIL PROTECTED] wrote: I'm assuming then you want the data to be able to contain _some_ mark-up considered to be safe? Not at this stage, no. Maybe if the users ask for it, but not now in the beginning. The universe's best engineer, Scotty, once advised us tell them that it's impossible, and only then to implement what they want. You should decide now before going any further, do you want the future capability to add mark-up codes? And if so, are they going to be similar to HTML using the and characters, or are they going to be like BBcode using the [ and ] characters? This decision will determine if filters to gaurd against XSS attacks really are the best solution or not. See, you should only use filters to prevent XSS attacks if you plan on using the and characters for mark-up codes (now or in the future). Otherwise, use htmlspecialchars() or htmlentities(). If you use a filter that strips and characters, you'll have a lot of angry / frustrated / confused users when they find they can't type and as literals if they're not aware that and are reserved for special mark-up codes. Consider: Suppose a bunch of mathematicians are having a discussion on the message board, and one of them decides to state that variable x is greater than 3. They might type x 3, but your filter will end up garbling it up. Not good! If you use htmlspecialchars(), then anything they type will appear as typed. If you want future capability for mark-up, you should inform the users which characters are reserved, and how they can represent them as literals. Basically, you're informing the users if they should speak HTML, speak BBcode, or speak the natural language when they post on the site. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 25/04/07, Justin Frim [EMAIL PROTECTED] wrote: Dotan Cohen wrote: On 25/04/07, Justin Frim [EMAIL PROTECTED] wrote: I'm assuming then you want the data to be able to contain _some_ mark-up considered to be safe? Not at this stage, no. Maybe if the users ask for it, but not now in the beginning. The universe's best engineer, Scotty, once advised us tell them that it's impossible, and only then to implement what they want. You should decide now before going any further, do you want the future capability to add mark-up codes? And if so, are they going to be similar to HTML using the and characters, or are they going to be like BBcode using the [ and ] characters? This decision will determine if filters to gaurd against XSS attacks really are the best solution or not. It would be BBcode if anything. It may be the product of the lazy, but I feel more secure parsing it than [x]HTML. See, you should only use filters to prevent XSS attacks if you plan on using the and characters for mark-up codes (now or in the future). Otherwise, use htmlspecialchars() or htmlentities(). If you use a filter that strips and characters, you'll have a lot of angry / frustrated / confused users when they find they can't type and as literals if they're not aware that and are reserved for special mark-up codes. Consider: Suppose a bunch of mathematicians are having a discussion on the message board, and one of them decides to state that variable x is greater than 3. They might type x 3, but your filter will end up garbling it up. Not good! If you use htmlspecialchars(), then anything they type will appear as typed. I currently an using htmlencode, so and show as expected. I do expect the math faculty to use those symbols :). If you want future capability for mark-up, you should inform the users which characters are reserved, and how they can represent them as literals. Basically, you're informing the users if they should speak HTML, speak BBcode, or speak the natural language when they post on the site. Right now it's speak the natural language, but I do not want to encumber the possibility of change. Thanks for the insight. Dotan Cohen http://dotancohen.com/eng/army_pictures.php http://iphanatics.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote: I currently an using htmlencode, so and show as expected. I do expect the math faculty to use those symbols :). Then you're already protected from XSS attacks, no HTML filters necessary. Easy as pi. ;-) (ok, that one was lame) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 26/04/07, Justin Frim [EMAIL PROTECTED] wrote: Then you're already protected from XSS attacks, no HTML filters necessary. Easy as pi. ;-) (ok, that one was lame) At least you didn't say ez as pi (ez would be 2.71 * Z variable, of course). Dotan Cohen http://lyricslist.com/lyrics/artist_albums/499/vitamin_c.html http://what-is-what.com/what_is/zip.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote: It would be BBcode if anything. It may be the product of the lazy, but I feel more secure parsing it than [x]HTML. BBCode is a pretty useless markup format. If you only want to allow / interpret a small subset of HTML, you can use a simple approach like this: http://shiflett.org/blog/2007/mar/allowing-html-and-preventing-xss If you want to allow a larger subset, or you're just looking for a packaged solution, try HTML Purifier: http://htmlpurifier.org/ Hope that helps. Chris -- Chris Shiflett http://shiflett.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 26/04/07, Chris Shiflett [EMAIL PROTECTED] wrote: Dotan Cohen wrote: It would be BBcode if anything. It may be the product of the lazy, but I feel more secure parsing it than [x]HTML. BBCode is a pretty useless markup format. If you only want to allow / interpret a small subset of HTML, you can use a simple approach like this: http://shiflett.org/blog/2007/mar/allowing-html-and-preventing-xss Thanks, Chris, I read that a few times through this week! I'll make the decision based upon the users: I'll see what they already know. The truth is, I'll probably not allow either. If you want to allow a larger subset, or you're just looking for a packaged solution, try HTML Purifier: http://htmlpurifier.org/ That is a great package. Dotan Cohen http://lyricslist.com/lyrics/artist_albums/136/crosby_bing.html http://what-is-what.com/what_is/3g.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Just my two cents worth...
Magic quotes are the work of the devil. It's a shame that so many PHP
installations have them enabled, and a huge disappointment that PHP is
actually distributed with this stuff enabled! The mere fact that a
script can't change this setting creates a real hassle and is my major
gripe about the whole situation. I've *always* followed the programming
practice of work with your data unencoded, then encode it appropriately
only at the last final output stage. That way you always know exactly
what you're working with, no surprises, where each character is always 1
byte, regardless of what character it is. Here's a typical block of
code which I include in the start of nearly all my PHP scripts:
?php
//Do not delete this function! (unless you don't mind data corruption
with PHP's default settings)
function stripslashes_deep($value) {
return is_array($value) ? array_map('stripslashes_deep', $value) :
stripslashes($value);
}
//Get rid of those stupid damn annoying asanine magic quotes which just
garble up your data.
if (get_magic_quotes_gpc()) {
/*
(unfortunately in PHP these are enabled by default. AHH! Which idiot
thought this was a good idea to turn them on by default? Good programming
practise is to manually encode only the data that requires encoding just
just before dumping it to places which need it (ie. databases), not
automatically screwing up the entire collection of the system's variables!
AHH!)
*/
$GLOBALS['HTTP_POST_VARS'] =
stripslashes_deep($GLOBALS['HTTP_POST_VARS']);
$GLOBALS['_POST'] = stripslashes_deep($GLOBALS['_POST']);
$GLOBALS['HTTP_GET_VARS'] = stripslashes_deep($GLOBALS['HTTP_GET_VARS']);
$GLOBALS['_GET'] = stripslashes_deep($GLOBALS['_GET']);
$GLOBALS['HTTP_COOKIE_VARS'] =
stripslashes_deep($GLOBALS['HTTP_COOKIE_VARS']);
$GLOBALS['_COOKIE'] = stripslashes_deep($GLOBALS['_COOKIE']);
$GLOBALS['HTTP_SERVER_VARS'] =
stripslashes_deep($GLOBALS['HTTP_SERVER_VARS']);
$GLOBALS['_SERVER'] = stripslashes_deep($GLOBALS['_SERVER']);
$GLOBALS['HTTP_ENV_VARS'] = stripslashes_deep($GLOBALS['HTTP_ENV_VARS']);
$GLOBALS['_ENV'] = stripslashes_deep($GLOBALS['_ENV']);
$GLOBALS['HTTP_POST_FILES'] =
stripslashes_deep($GLOBALS['HTTP_POST_FILES']);
$GLOBALS['_FILES'] = stripslashes_deep($GLOBALS['_FILES']);
$GLOBALS['_REQUEST'] = stripslashes_deep($GLOBALS['_REQUEST']);
}
set_magic_quotes_runtime (0); //Fortunately these can be killed with a
single statement, unlike magic_quotes_gpc
?
Eh, don't mind the comments. Sometimes PHP programming can become quite
frustrating. ;-)
On to the next stage... encoding data for output to an HTML document.
Personally, I prefer using htmlspecialchars() over htmlentities(),
because it only converts those characters that *must* be converted for
HTML ( ). There's no use in turning your other 1-byte
characters into 5, 6, or 7-byte strings, if you already provided the
correct character set in the Content-Type HTTP header (as you should!).
Actually, if you want to get really picky, I usually use the following
conversions:
For most tag parameters: htmlspecialchars($tagdata)
For display text: nl2br(htmlspecialchars($displaytext))
(This keeps newline sequences in effect.)
For text which may contain a few control characters, special characters,
or other binary data (sometimes useful in hidden form fields, or for
special accented characters and non-english languages):
preg_replace('/([\\x00-\\x1F\\x7F-\\xFF])/e','#.ord(substr($1,-1)).;',htmlspecialchars($binarytext))
(This encodes the data in a mostly still human-readable form, entirely
with 7-bit ASCII characters only.)
For binary data (sometimes useful in hidden form fields):
strtr(base64_encode($binarydata),'+/=','-_.');
(All the advantages of Base64 encoding, without incurring any overhead
from URL encoding when the form is submitted.)
Anyhow, back on track to the original topic of this thread. For
anything that gets written to a database or used for a query, I suggest
escaping the data using a function specifically designed for that
database. (And there are many different functions for the many
different popular databases.) This should have *nothing* to do with
blocking XSS, turning into lt;, etc. Preparing for the database
query string is no place to do the data conversion which will be
necessary for the final output.
The last topic... blocking XSS attacks. If you use the encoding
routines I listed above for outputting to HTML documents, you're already
safe. And you're not outlawing any characters either... if someone
wants to type and , or show semi-colons or whatever, they can,
knowing with certainty that what they type is exactly what others will
see. If you need to let users enter some mark-up, do what message
boards and web log sites have been doing for years: BBcode. Then you
can write your own routines to provide only the features you need, using
a code format that's much
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 24/04/07, Justin Frim [EMAIL PROTECTED] wrote:
Just my two cents worth...
Magic quotes are the work of the devil. It's a shame that so many PHP
installations have them enabled, and a huge disappointment that PHP is
actually distributed with this stuff enabled! The mere fact that a
script can't change this setting creates a real hassle and is my major
gripe about the whole situation. I've *always* followed the programming
practice of work with your data unencoded, then encode it appropriately
only at the last final output stage. That way you always know exactly
what you're working with, no surprises, where each character is always 1
byte, regardless of what character it is. Here's a typical block of
code which I include in the start of nearly all my PHP scripts:
?php
//Do not delete this function! (unless you don't mind data corruption
with PHP's default settings)
function stripslashes_deep($value) {
return is_array($value) ? array_map('stripslashes_deep', $value) :
stripslashes($value);
}
//Get rid of those stupid damn annoying asanine magic quotes which just
garble up your data.
if (get_magic_quotes_gpc()) {
/*
(unfortunately in PHP these are enabled by default. AHH! Which idiot
thought this was a good idea to turn them on by default? Good programming
practise is to manually encode only the data that requires encoding just
You've got a typo in practice.
just before dumping it to places which need it (ie. databases), not
automatically screwing up the entire collection of the system's variables!
AHH!)
*/
$GLOBALS['HTTP_POST_VARS'] =
stripslashes_deep($GLOBALS['HTTP_POST_VARS']);
$GLOBALS['_POST'] = stripslashes_deep($GLOBALS['_POST']);
$GLOBALS['HTTP_GET_VARS'] = stripslashes_deep($GLOBALS['HTTP_GET_VARS']);
$GLOBALS['_GET'] = stripslashes_deep($GLOBALS['_GET']);
$GLOBALS['HTTP_COOKIE_VARS'] =
stripslashes_deep($GLOBALS['HTTP_COOKIE_VARS']);
$GLOBALS['_COOKIE'] = stripslashes_deep($GLOBALS['_COOKIE']);
$GLOBALS['HTTP_SERVER_VARS'] =
stripslashes_deep($GLOBALS['HTTP_SERVER_VARS']);
$GLOBALS['_SERVER'] = stripslashes_deep($GLOBALS['_SERVER']);
$GLOBALS['HTTP_ENV_VARS'] = stripslashes_deep($GLOBALS['HTTP_ENV_VARS']);
$GLOBALS['_ENV'] = stripslashes_deep($GLOBALS['_ENV']);
$GLOBALS['HTTP_POST_FILES'] =
stripslashes_deep($GLOBALS['HTTP_POST_FILES']);
$GLOBALS['_FILES'] = stripslashes_deep($GLOBALS['_FILES']);
$GLOBALS['_REQUEST'] = stripslashes_deep($GLOBALS['_REQUEST']);
}
set_magic_quotes_runtime (0); //Fortunately these can be killed with a
single statement, unlike magic_quotes_gpc
?
That's bad. For a function that was meant to make life easier, magic
quotes sure has caused a bit of problems. I believe that it will be
not available in php6.
Eh, don't mind the comments. Sometimes PHP programming can become quite
frustrating. ;-)
On to the next stage... encoding data for output to an HTML document.
Personally, I prefer using htmlspecialchars() over htmlentities(),
because it only converts those characters that *must* be converted for
HTML ( ). There's no use in turning your other 1-byte
characters into 5, 6, or 7-byte strings, if you already provided the
correct character set in the Content-Type HTTP header (as you should!).
Actually, if you want to get really picky, I usually use the following
conversions:
For most tag parameters: htmlspecialchars($tagdata)
For display text: nl2br(htmlspecialchars($displaytext))
(This keeps newline sequences in effect.)
For text which may contain a few control characters, special characters,
or other binary data (sometimes useful in hidden form fields, or for
special accented characters and non-english languages):
preg_replace('/([\\x00-\\x1F\\x7F-\\xFF])/e','#.ord(substr($1,-1)).;',htmlspecialchars($binarytext))
(This encodes the data in a mostly still human-readable form, entirely
with 7-bit ASCII characters only.)
For binary data (sometimes useful in hidden form fields):
strtr(base64_encode($binarydata),'+/=','-_.');
(All the advantages of Base64 encoding, without incurring any overhead
from URL encoding when the form is submitted.)
Anyhow, back on track to the original topic of this thread. For
anything that gets written to a database or used for a query, I suggest
escaping the data using a function specifically designed for that
database. (And there are many different functions for the many
different popular databases.) This should have *nothing* to do with
blocking XSS, turning into lt;, etc. Preparing for the database
query string is no place to do the data conversion which will be
necessary for the final output.
I took chris's advice and filter for XSS after the info is retrieved
from the database, before sending it to the browser.
The last topic... blocking XSS attacks. If you use the encoding
routines I listed above for outputting to HTML documents, you're already
safe. And you're not outlawing any characters either... if someone
wants to type and , or show semi-colons
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 4/24/07, Dotan Cohen [EMAIL PROTECTED] wrote:
Thanks. Most of that has already been done now, but I'll certainly
keep your functions handy. I'll likely need them at some point.
One thing you might want to keep in mind is that this little fix is
going to get executed on each request if you just throw it in an
include. I ran stripslashes_deep() against my 5.2.1 release and here
are the results:
Version: 2.0.0RC3
TRACE START [2007-04-24 21:37:47]
1 0 0 0.00441572400 {main} 1
/Users/eric/Sites/meh.php 0
2 1 0 0.00453874328 get_magic_quotes_gpc
0 /Users/eric/Sites/meh.php 8
2 1 1 0.00458674328
2 2 0 0.00462274328 stripslashes_deep
1 /Users/eric/Sites/meh.php 18
snip
2 251 0 0.02169386560
set_magic_quotes_runtime0
/Users/eric/Sites/meh.php 35
2 251 1 0.02195086560
1 0 1 0.02201384632
0.0223 33416
TRACE END [2007-04-24 21:37:47]
That means lots function calls happened before you could even say
hello world. You might want to add wrapper functions accessor
functions around $_GET and $_POST so that you're only stripping when
really necessary.
You might also consider reading this
http://ez.no/community/articles/dangers_of_csrf_and_xss by Ilia
Alshanetsky.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Preventing SQL Injection/ Cross Site Scripting
On Mon, April 23, 2007 9:48 am, WeberSites LTD wrote: I'm trying to understand from the examples why anyone that has get_magic_quotes_gpc() returning true would need to use stripslashes() and then mysql_real_escape_string(). wouldn't that just add slashes to the same places? If you were 100% sure that everybody on the planet spoke only English, and only used the ASCII codeset, sure, it's the same thing... Oh, wait. Earth has more than one language, doesn't it? :-) mysql_real_escape_string() takes into account the charset[s] being used. addslashes assumes ASCII charset. Don't do that. YOU may not be expecting the Spanish Inquisition, but somebody will be trying to send it to you. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On Tue, April 24, 2007 3:33 pm, Justin Frim wrote: (unfortunately in PHP these are enabled by default. AHH! Which idiot thought this was a good idea to turn them on by default? Rasmus thought it was a Good Idea because it was very convenient for his needs at the time, which as simple form processing, cramming it into the DB, in an era where SQL injection and XSS attacks had about the same contextual relevance as AIDS had in the the Summer of Love... (I.e., none) Then we were trying to avoid breaking BC in a big way, which may have been a mistake, but there it is. I think maybe I recall reading that PHP 6 won't even have Magic Quotes, much less have them on by default... But maybe that was just a dream... You can Google for Derick Rethan's (sp?) Paris PHP Meeting Notes of a PHP 6 roadmap and find out for sure, or check Lukas' PHP ToDo Wiki to be even more current/certain. PS It's sure a lot easier when you have some control over the environment and can just turn the dang things off in .htacess :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Eric Butera wrote: One thing you might want to keep in mind is that this little fix is going to get executed on each request if you just throw it in an include. ...big snip... That means lots function calls happened before you could even say hello world. You might want to add wrapper functions accessor functions around $_GET and $_POST so that you're only stripping when really necessary. You could always take out the lines from that fix which you don't need. For example, if you use the $_POST[] array, you probably don't need to fix $HTTP_POST_VARS too, and if you don't use cookies at all, there's no need to spend CPU cycles un-magic_quote_gpc'ing any of the cookie stuff. The problem with wrappers is they're always executed, even for people who don't have the magic quotes problem. What I liked about lumping it all together as a massive operation at the start is I could put my fix in a single if() block to skip it if it's not necessary. Those who have PHP installations that aren't tainted with magic_quotes_gpc can run the script with almost no performance hit at all... faster than if the script had wrappers. It also keeps the rest of the code pretty. ;-) If you're frequently accessing a superglobal through a wrapper (for example in a loop where you compare it with values in a long array or something), you're still back to executing several function calls. That's just out of the frying pan and into the fire. Of course a smart optimization would be to call the wrapper only once, declare a variable to store the result, and use this variable for comparison inside your loop. Now if we extend that mentality even further we can declare the variable as global at the start of the script and call the wrapper only once at the start too! Now we've essentially created an un-magic_quote_gpc'd copy of the superglobal. So the next logical thought is if we're never using the magic quoted value in the code, why make a *copy* of the superglobal? Why not just operate *directly* on it?. That's the train of thought that led to my little fix anyhow. :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote:
On 24/04/07, Justin Frim [EMAIL PROTECTED] wrote:
if (get_magic_quotes_gpc()) {
/*
(unfortunately in PHP these are enabled by default. AHH! Which idiot
thought this was a good idea to turn them on by default? Good
programming
practise is to manually encode only the data that requires encoding
just
You've got a typo in practice.
I seem to recall I was in a very, very bad mood when I wrote that
comment. *L*
While I do normally strip out all my nasty comments before making code
go public, I still keep them in some of my personal scripts for
historical humour among friends. But thanks... I'll try to keep that in
mind. :-)
I took chris's advice and filter for XSS after the info is retrieved
from the database, before sending it to the browser.
I'm assuming then you want the data to be able to contain _some_ mark-up
considered to be safe?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Preventing SQL Injection/ Cross Site Scripting
I'm trying to understand from the examples why anyone
that has get_magic_quotes_gpc() returning true would
need to use stripslashes() and then mysql_real_escape_string().
wouldn't that just add slashes to the same places?
berber
-Original Message-
From: Buesching, Logan J [mailto:[EMAIL PROTECTED]
Sent: Monday, April 23, 2007 2:35 AM
To: Dotan Cohen; php php
Subject: RE: [PHP] Preventing SQL Injection/ Cross Site Scripting
There are many good resources out there, and one of my favorites for this
type of information is from Chris Shiflett.
http://shiflett.org/articles/sql-injection
http://shiflett.org/articles/foiling-cross-site-attacks
http://shiflett.org/blog/2007/mar/allowing-html-and-preventing-xss
Those are a few articles on the subject, maybe some reader comments have
more good links.
Also, just as a best-practice, you usually don't want to reassign things
into the super globals. Also to note, your filtering may be a bit too
aggressive, and not all-inclusive at the same time. Too aggressive because
if I want to talk about java in a comment, it will filter out every time I
say java. Too lax because you are forgetting all of the HTML onclick,
onhover etc... that don't need to have a script tag in them to be
executed. Any of the preg_replace's with an = in them is redundant because
you have already filtered out all of the ='s, but also note that you can
have multiple spaces between href and =. You are banking that they will
have 0 or 1.
If available, you can look into PHP 5.2 which added some filter functions
(albeit I myself haven't checked them out). You can also look into OWASP's
PHP project, http://www.owasp.org/index.php/Category:OWASP_PHP_Project.
That is a pretty good resource in secure coding best-practices.
-Logan
-Original Message-
From: Dotan Cohen [mailto:[EMAIL PROTECTED]
Sent: Friday, April 20, 2007 9:08 PM
To: php php
Subject: [PHP] Preventing SQL Injection/ Cross Site Scripting
I've got a comments form that I'd like to harden against SQL Injection / XSS
attacks. The data is stored in UTF-8 in a mysql database. I currently parse
the data as such:
$_POST[commentform]=str_replace (', '', $_POST[commentform]);
//q-qq
$_POST[commentform]=str_replace (--, , $_POST[commentform]);
//-- - x
$_POST[commentform]=str_replace (;, , $_POST[commentform]);
//; - x
$_POST[commentform]=str_replace (=, '', $_POST[commentform]);
//= - x
$_POST[commentform]=preg_replace (/java/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/script/i, '',
$_POST[commentform]); $_POST[commentform]=preg_replace (/src=/i, '',
$_POST[commentform]); $_POST[commentform]=preg_replace (/src =/i,
'', $_POST[commentform]); $_POST[commentform]=preg_replace
(/iframe/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/rel=/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/rel =/i, '',
$_POST[commentform]); $_POST[commentform]=preg_replace (/href=/i,
'', $_POST[commentform]); $_POST[commentform]=preg_replace (/href
=/i, '', $_POST[commentform]); $_POST[commentform]=preg_replace
(//i, '', $_POST[commentform]);
$_POST[commentform]=htmlspecialchars( mysql_real_escape_string
($_POST[commentform]) );
The first statement doubles up quotes, it's a bit difficult to see in the
code.
After seeing this:
http://ha.ckers.org/xss.html
and another similar one for SQL injection, I'm worried that my filters are
not enough. What do the pro php programers out there use?
Thanks in advance.
Dotan Cohen
http://lyricslist.com/
http://what-is-what.com/
--
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] Preventing SQL Injection/ Cross Site Scripting
On 4/23/07, WeberSites LTD [EMAIL PROTECTED] wrote: I'm trying to understand from the examples why anyone that has get_magic_quotes_gpc() returning true would need to use stripslashes() and then mysql_real_escape_string(). wouldn't that just add slashes to the same places? berber Yes, sort of... mysql_real_escape_string() considers character sets before escaping. There is a difference. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Preventing SQL Injection/ Cross Site Scripting
No. That is a common mistake amongst the uninformed. Addslashes
doesn't take into effect character encodings, while
mysql_real_escape_string does. Please take a look at this article:
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-st
ring
-Logan
-Original Message-
From: Weber Sites [mailto:[EMAIL PROTECTED] On Behalf Of WeberSites
LTD
Sent: Monday, April 23, 2007 10:49 AM
To: Buesching, Logan J; 'Dotan Cohen'; 'php php'
Subject: RE: [PHP] Preventing SQL Injection/ Cross Site Scripting
I'm trying to understand from the examples why anyone
that has get_magic_quotes_gpc() returning true would
need to use stripslashes() and then mysql_real_escape_string().
wouldn't that just add slashes to the same places?
berber
-Original Message-
From: Buesching, Logan J [mailto:[EMAIL PROTECTED]
Sent: Monday, April 23, 2007 2:35 AM
To: Dotan Cohen; php php
Subject: RE: [PHP] Preventing SQL Injection/ Cross Site Scripting
There are many good resources out there, and one of my favorites for
this
type of information is from Chris Shiflett.
http://shiflett.org/articles/sql-injection
http://shiflett.org/articles/foiling-cross-site-attacks
http://shiflett.org/blog/2007/mar/allowing-html-and-preventing-xss
Those are a few articles on the subject, maybe some reader comments have
more good links.
Also, just as a best-practice, you usually don't want to reassign things
into the super globals. Also to note, your filtering may be a bit too
aggressive, and not all-inclusive at the same time. Too aggressive
because
if I want to talk about java in a comment, it will filter out every time
I
say java. Too lax because you are forgetting all of the HTML onclick,
onhover etc... that don't need to have a script tag in them to be
executed. Any of the preg_replace's with an = in them is redundant
because
you have already filtered out all of the ='s, but also note that you can
have multiple spaces between href and =. You are banking that they will
have 0 or 1.
If available, you can look into PHP 5.2 which added some filter
functions
(albeit I myself haven't checked them out). You can also look into
OWASP's
PHP project, http://www.owasp.org/index.php/Category:OWASP_PHP_Project.
That is a pretty good resource in secure coding best-practices.
-Logan
-Original Message-
From: Dotan Cohen [mailto:[EMAIL PROTECTED]
Sent: Friday, April 20, 2007 9:08 PM
To: php php
Subject: [PHP] Preventing SQL Injection/ Cross Site Scripting
I've got a comments form that I'd like to harden against SQL Injection /
XSS
attacks. The data is stored in UTF-8 in a mysql database. I currently
parse
the data as such:
$_POST[commentform]=str_replace (', '', $_POST[commentform]);
//q-qq
$_POST[commentform]=str_replace (--, , $_POST[commentform]);
//-- - x
$_POST[commentform]=str_replace (;, , $_POST[commentform]);
//; - x
$_POST[commentform]=str_replace (=, '', $_POST[commentform]);
//= - x
$_POST[commentform]=preg_replace (/java/i, '',
$_POST[commentform]);
$_POST[commentform]=preg_replace (/script/i, '',
$_POST[commentform]); $_POST[commentform]=preg_replace (/src=/i,
'',
$_POST[commentform]); $_POST[commentform]=preg_replace (/src =/i,
'', $_POST[commentform]); $_POST[commentform]=preg_replace
(/iframe/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/rel=/i, '',
$_POST[commentform]);
$_POST[commentform]=preg_replace (/rel =/i, '',
$_POST[commentform]); $_POST[commentform]=preg_replace (/href=/i,
'', $_POST[commentform]); $_POST[commentform]=preg_replace (/href
=/i, '', $_POST[commentform]); $_POST[commentform]=preg_replace
(//i, '', $_POST[commentform]);
$_POST[commentform]=htmlspecialchars( mysql_real_escape_string
($_POST[commentform]) );
The first statement doubles up quotes, it's a bit difficult to see in
the
code.
After seeing this:
http://ha.ckers.org/xss.html
and another similar one for SQL injection, I'm worried that my filters
are
not enough. What do the pro php programers out there use?
Thanks in advance.
Dotan Cohen
http://lyricslist.com/
http://what-is-what.com/
--
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] Preventing SQL Injection/ Cross Site Scripting
There are many good resources out there, and one of my favorites for this type
of information is from Chris Shiflett.
http://shiflett.org/articles/sql-injection
http://shiflett.org/articles/foiling-cross-site-attacks
http://shiflett.org/blog/2007/mar/allowing-html-and-preventing-xss
Those are a few articles on the subject, maybe some reader comments have more
good links.
Also, just as a best-practice, you usually don't want to reassign things into
the super globals. Also to note, your filtering may be a bit too aggressive,
and not all-inclusive at the same time. Too aggressive because if I want to
talk about java in a comment, it will filter out every time I say java. Too
lax because you are forgetting all of the HTML onclick, onhover etc... that
don't need to have a script tag in them to be executed. Any of the
preg_replace's with an = in them is redundant because you have already filtered
out all of the ='s, but also note that you can have multiple spaces between
href and =. You are banking that they will have 0 or 1.
If available, you can look into PHP 5.2 which added some filter functions
(albeit I myself haven't checked them out). You can also look into OWASP's PHP
project, http://www.owasp.org/index.php/Category:OWASP_PHP_Project. That is a
pretty good resource in secure coding best-practices.
-Logan
-Original Message-
From: Dotan Cohen [mailto:[EMAIL PROTECTED]
Sent: Friday, April 20, 2007 9:08 PM
To: php php
Subject: [PHP] Preventing SQL Injection/ Cross Site Scripting
I've got a comments form that I'd like to harden against SQL Injection
/ XSS attacks. The data is stored in UTF-8 in a mysql database. I
currently parse the data as such:
$_POST[commentform]=str_replace (', '', $_POST[commentform]);
//q-qq
$_POST[commentform]=str_replace (--, , $_POST[commentform]);
//-- - x
$_POST[commentform]=str_replace (;, , $_POST[commentform]);
//; - x
$_POST[commentform]=str_replace (=, '', $_POST[commentform]);
//= - x
$_POST[commentform]=preg_replace (/java/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/script/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/src=/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/src =/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/iframe/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/rel=/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/rel =/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/href=/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/href =/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (//i, '', $_POST[commentform]);
$_POST[commentform]=htmlspecialchars( mysql_real_escape_string
($_POST[commentform]) );
The first statement doubles up quotes, it's a bit difficult to see in the code.
After seeing this:
http://ha.ckers.org/xss.html
and another similar one for SQL injection, I'm worried that my filters
are not enough. What do the pro php programers out there use?
Thanks in advance.
Dotan Cohen
http://lyricslist.com/
http://what-is-what.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Preventing SQL Injection/ Cross Site Scripting
-Message d'origine- De : Dotan Cohen [mailto:[EMAIL PROTECTED] Envoyé : samedi 21 avril 2007 03:08 À : php php Objet : [PHP] Preventing SQL Injection/ Cross Site Scripting I've got a comments form that I'd like to harden against SQL Injection / XSS attacks. The data is stored in UTF-8 in a mysql database. I currently parse the data as such: ... The first statement doubles up quotes, it's a bit difficult to see in the code. After seeing this: http://ha.ckers.org/xss.html and another similar one for SQL injection, I'm worried that my filters are not enough. What do the pro php programers out there use? Sql and xss attacks are two different issues that should each be adressed accordingly at at the right time... XSS attacks should be parsed when the form is checked, sql should be adresssed when you are puting the actuall information in the database. PHP has several functions that adress sql injection issues for example as stated: mysql_real_escape_string(); which will safely escape any data used in an sql statement to evade sql injection, thats a good first measure any ways... Second, a mesure that i take for both xss and sql is instead of escaping certain data, i only allow certain data, that i consider safe for display on a web site.. I recommend you dig deeper into that xss page you might even find a script that filters xss.. You might even be able to modify it to suit your needs and/or to harden/better it... Regards, Tim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 21/04/07, Leonard Burton [EMAIL PROTECTED] wrote: Hi Dotan, Why not use mysql_escape_string()? I use mysql_real_escape_string() as the second to last function in there. Dotan Cohen http://dotancohen.com/eng/army_pictures.php http://lyricslist.com/lyrics/artist_albums/575/7a3.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 21/04/07, Tim [EMAIL PROTECTED] wrote: -Message d'origine- De : Dotan Cohen [mailto:[EMAIL PROTECTED] Envoyé : samedi 21 avril 2007 03:08 À : php php Objet : [PHP] Preventing SQL Injection/ Cross Site Scripting I've got a comments form that I'd like to harden against SQL Injection / XSS attacks. The data is stored in UTF-8 in a mysql database. I currently parse the data as such: ... The first statement doubles up quotes, it's a bit difficult to see in the code. After seeing this: http://ha.ckers.org/xss.html and another similar one for SQL injection, I'm worried that my filters are not enough. What do the pro php programers out there use? Sql and xss attacks are two different issues that should each be adressed accordingly at at the right time... XSS attacks should be parsed when the form is checked, sql should be adresssed when you are puting the actuall information in the database. The information is inserted into the database right after it is checked. PHP has several functions that adress sql injection issues for example as stated: mysql_real_escape_string(); which will safely escape any data used in an sql statement to evade sql injection, thats a good first measure any ways... Yes, that is the second to last function that I'm using. Second, a mesure that i take for both xss and sql is instead of escaping certain data, i only allow certain data, that i consider safe for display on a web site.. Although I can semicolons and the like, greater than and less than signs I want to keep as there are some rather witty people from the Mathematics faculty who will be using the comments. I'll str_replace() them to gt; and lt; however. I recommend you dig deeper into that xss page you might even find a script that filters xss.. You might even be able to modify it to suit your needs and/or to harden/better it... Obviously I keep missing it. I've reread it twice since you mention there is a filter script and can't find it. I've followed most of the links as well. I'll keep looking. Dotan Cohen http://what-is-what.com/what_is/blog.html http://ultu.com
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
2007. 04. 21, szombat keltezéssel 13.20-kor Dotan Cohen ezt írta: On 21/04/07, Tim [EMAIL PROTECTED] wrote: -Message d'origine- De : Dotan Cohen [mailto:[EMAIL PROTECTED] Envoyé : samedi 21 avril 2007 03:08 À : php php Objet : [PHP] Preventing SQL Injection/ Cross Site Scripting I've got a comments form that I'd like to harden against SQL Injection / XSS attacks. The data is stored in UTF-8 in a mysql database. I currently parse the data as such: ... The first statement doubles up quotes, it's a bit difficult to see in the code. After seeing this: http://ha.ckers.org/xss.html and another similar one for SQL injection, I'm worried that my filters are not enough. What do the pro php programers out there use? Sql and xss attacks are two different issues that should each be adressed accordingly at at the right time... XSS attacks should be parsed when the form is checked, sql should be adresssed when you are puting the actuall information in the database. The information is inserted into the database right after it is checked. PHP has several functions that adress sql injection issues for example as stated: mysql_real_escape_string(); which will safely escape any data used in an sql statement to evade sql injection, thats a good first measure any ways... Yes, that is the second to last function that I'm using. Second, a mesure that i take for both xss and sql is instead of escaping certain data, i only allow certain data, that i consider safe for display on a web site.. Although I can semicolons and the like, greater than and less than signs I want to keep as there are some rather witty people from the Mathematics faculty who will be using the comments. I'll str_replace() them to gt; and lt; however. what about htmlentities()? http://php.net/htmlentities greets Zoltán Németh I recommend you dig deeper into that xss page you might even find a script that filters xss.. You might even be able to modify it to suit your needs and/or to harden/better it... Obviously I keep missing it. I've reread it twice since you mention there is a filter script and can't find it. I've followed most of the links as well. I'll keep looking. Dotan Cohen http://what-is-what.com/what_is/blog.html http://ultu.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
At 4:08 AM +0300 4/21/07, Dotan Cohen wrote: I've got a comments form that I'd like to harden against SQL Injection / XSS attacks. The data is stored in UTF-8 in a mysql database. I currently parse the data as such: I highly recommend Essential PHP Security by Chris Shiflett -- he covers those issues and more in detail. It's well worth the cost and you can get it used for as little $12.81. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote: I recommend you dig deeper into that xss page you might even find a script that filters xss. Obviously I keep missing it. You might find these examples useful: http://phpsecurity.org/code/ch01-3 http://phpsecurity.org/code/ch01-4 Hope that helps. Chris -- Chris Shiflett http://shiflett.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 21/04/07, tedd [EMAIL PROTECTED] wrote: At 4:08 AM +0300 4/21/07, Dotan Cohen wrote: I've got a comments form that I'd like to harden against SQL Injection / XSS attacks. The data is stored in UTF-8 in a mysql database. I currently parse the data as such: I highly recommend Essential PHP Security by Chris Shiflett -- he covers those issues and more in detail. It's well worth the cost and you can get it used for as little $12.81. Thanks, I see it used on Amazon for $12.81 in like new condition, with another $10 to ship it. I might just do that as I cannot get those books locally. Dotan Cohen http://what-is-what.com/what_is/blog.html http://ultu.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On 21/04/07, Chris Shiflett [EMAIL PROTECTED] wrote: Dotan Cohen wrote: I recommend you dig deeper into that xss page you might even find a script that filters xss. Obviously I keep missing it. You might find these examples useful: http://phpsecurity.org/code/ch01-3 http://phpsecurity.org/code/ch01-4 Hope that helps. Chris Thanks, Chris. I think that I see your book in my future! One note, I remove semicolons from the user input to thrart SQL injection as they can be used to terminate an SQL query and are very uncommon in regular speech. However, htmlspecialchars() and htmlentities add semicolons when converting. Is this dangerous, ie, can this be exploited? Dotan Cohen http://what-is-what.com/what_is/sitepoint.html http://lyricslist.com/lyrics/artist_albums/466/sugar_ray.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote: One note, I remove semicolons from the user input to thrart SQL injection as they can be used to terminate an SQL query and are very uncommon in regular speech. However, htmlspecialchars() and htmlentities add semicolons when converting. Is this dangerous, ie, can this be exploited? If you ever use htmlentities() to escape data for SQL or mysql_real_escape_string() to escape data for HTML, then yes, it is dangerous. Escaping functions are context-dependent. Hope that helps. Chris -- Chris Shiflett http://shiflett.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On Fri, April 20, 2007 8:08 pm, Dotan Cohen wrote: I've got a comments form that I'd like to harden against SQL Injection / XSS attacks. The data is stored in UTF-8 in a mysql database. I currently parse the data as such: After seeing this: http://ha.ckers.org/xss.html and another similar one for SQL injection, I'm worried that my filters are not enough. What do the pro php programers out there use? http://phpsec.org For MySQL: http://mysql_real_escape_string -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
On Sat, April 21, 2007 5:20 am, Dotan Cohen wrote: Although I can semicolons and the like, greater than and less than signs I want to keep as there are some rather witty people from the Mathematics faculty who will be using the comments. I'll str_replace() them to gt; and lt; however. Store the original data (after mysql escaping). Upon output to a browser, *ANY* data should have htmlentities() called on it, unless you really really trust the author and have a secure chain of evidence that it's kosher to let them put HTML/JS on your site. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Hi Dotan,
Why not use mysql_escape_string()?
On 4/20/07, Dotan Cohen [EMAIL PROTECTED] wrote:
I've got a comments form that I'd like to harden against SQL Injection
/ XSS attacks. The data is stored in UTF-8 in a mysql database. I
currently parse the data as such:
$_POST[commentform]=str_replace (', '', $_POST[commentform]);
//q-qq
$_POST[commentform]=str_replace (--, , $_POST[commentform]);
//-- - x
$_POST[commentform]=str_replace (;, , $_POST[commentform]);
//; - x
$_POST[commentform]=str_replace (=, '', $_POST[commentform]);
//= - x
$_POST[commentform]=preg_replace (/java/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/script/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/src=/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/src =/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/iframe/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/rel=/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/rel =/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/href=/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (/href =/i, '', $_POST[commentform]);
$_POST[commentform]=preg_replace (//i, '', $_POST[commentform]);
$_POST[commentform]=htmlspecialchars( mysql_real_escape_string
($_POST[commentform]) );
The first statement doubles up quotes, it's a bit difficult to see in the code.
After seeing this:
http://ha.ckers.org/xss.html
and another similar one for SQL injection, I'm worried that my filters
are not enough. What do the pro php programers out there use?
Thanks in advance.
Dotan Cohen
http://lyricslist.com/
http://what-is-what.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Leonard Burton, N9URK
http://www.jiffyslides.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]
The prolonged evacuation would have dramatically affected the
survivability of the occupants.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
