RE: [PHP] Security Question
At 2:53 PM -0500 4/8/11, Jay Blanchard wrote: [snip] whats the best way to learn about security in php? [/snip] Study, study, study! Chris Shiflett is a recognized expert on PHP security - http://shiflett.org/ He has a great book on PHP Security - http://www.amazon.com/exec/obidos/ASIN/059600656X/ref=nosim/chrisshiflet t-20 !++ Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Question
On Fri, Apr 8, 2011 at 3:24 PM, nighthawk1256 wrote: > hey guys/girls, > > whats the best way to learn about security in php? Here are some relevant topics to consider: - Validate input (only accept what you're expecting, via GET, POST, and COOKIE, and don't try to fix an invalid value, throw it out.) - Use prepared statements (PDO makes this easy and generalizes quite well across popular DB's.) - Only give the bare minimum permissions required to accomplish a task (e.g., I usually have one SQL user account for reads, and one that allows for reads and writes.) - When errors occur, don't leak important system information to your users. - Hash passwords (with a salt) that are stored so you're never storing the literal value. - If you use an authentication system that's implemented with cookies (sessions-based or custom), all requests should run over https instead of http. - Escape output according to context (html, attribute, or url.) If you google the above topics, you'll find some great sites/blogs that address these topics in detail. Adam P.S. - Or, you can just use my one-file web framework which helps you automatically address all but the https issue above :) Sorry, it's a Friday so I couldn't resist the shameless plug. -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
RE: [PHP] Security Question
Best way to learn about security of something is to learn how to break it... On Apr 8, 2011 3:55 PM, "Jay Blanchard" wrote: > > [snip] > whats the best way to learn about security in php? > [/snip] > > Study, study, study! > > Chris Shiflett is a recognized expert on PHP security - > http://shiflett.org/ > > He has a great book on PHP Security - > http://www.amazon.com/exec/obidos/ASIN/059600656X/ref=nosim/chrisshiflet > t-20 > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >
RE: [PHP] Security Question
[snip] whats the best way to learn about security in php? [/snip] Study, study, study! Chris Shiflett is a recognized expert on PHP security - http://shiflett.org/ He has a great book on PHP Security - http://www.amazon.com/exec/obidos/ASIN/059600656X/ref=nosim/chrisshiflet t-20 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] [security] PHP has DoS vuln with large decimal points
hi, On Mon, Jan 17, 2011 at 5:21 AM, Tommy Pham wrote: > Thanks Dan. I'll keep it in mind for the future. For interested parties, > that's found in the official Windows 5.3.3 NTS VC9 build. Works fine with > the current official 5.3.5 NTS VC9. 5.3.5 was released only to fix this exact bug :-) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] [security] PHP has DoS vuln with large decimal points
> -Original Message-
> From: paras...@gmail.com [mailto:paras...@gmail.com] On Behalf Of
> Daniel Brown
> Sent: Sunday, January 16, 2011 7:00 PM
> To: Tommy Pham
> Cc: PHP General; PHP Internals List; secur...@php.net
> Subject: Re: [PHP] [security] PHP has DoS vuln with large decimal points
>
> On Sun, Jan 16, 2011 at 21:00, Tommy Pham wrote:
> >
> > Here are the results after some further tests for the same platform:
> >
> > * max float value: 1.7976931348623E+308
> > * min float value: 9.8813129168249E-324 <<
> > floatval('1.00e-323') weird ...
> >
> > PHP wil hang when the value is between (inclusive)
> >
> > floatval('2.22507385850720102e-308') -
> > floatval('2.22507385850720113e-308')
> >
> > I can't find the bug report for the issue @ bugs.php.net. Does anyone
> > know if one is submitted? I should submit one? Sucribe to dev list
> > and go from there?
>
> If in doubt, file a bug. Worse comes to worst, it will be marked as
bogus or
> a duplicate. For security-related things, send them to secur...@php.net,
> not to the General list. Again, if it's of no concern, it will simply be
ignored
> as bogus or already known.
>
> --
>
> Network Infrastructure Manager
> Documentation, Webmaster Teams
> http://www.php.net/
Thanks Dan. I'll keep it in mind for the future. For interested parties,
that's found in the official Windows 5.3.3 NTS VC9 build. Works fine with
the current official 5.3.5 NTS VC9.
Thanks,
Tommy
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PHP-DEV] Re: [PHP] [security] PHP has DoS vuln with large decimal points
On 2011-01-16, at 9:59 PM, Daniel Brown wrote:
> On Sun, Jan 16, 2011 at 21:00, Tommy Pham wrote:
>>
>> Here are the results after some further tests for the same platform:
>>
>> * max float value: 1.7976931348623E+308
>> * min float value: 9.8813129168249E-324 <<
>> floatval('1.00e-323') weird ...
>>
>> PHP wil hang when the value is between (inclusive)
>>
>> floatval('2.22507385850720102e-308') -
>> floatval('2.22507385850720113e-308')
>>
>> I can't find the bug report for the issue @ bugs.php.net. Does anyone know
>> if one is submitted? I should submit one? Sucribe to dev list and go from
>> there?
>
>If in doubt, file a bug. Worse comes to worst, it will be marked
> as bogus or a duplicate. For security-related things, send them to
> secur...@php.net, not to the General list. Again, if it's of no
> concern, it will simply be ignored as bogus or already known
Is this not it?
http://bugs.php.net/53632
Best Regards
Mike Robinson
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] [security] PHP has DoS vuln with large decimal points
> -Original Message- > From: Jim Lucas [mailto:li...@cmsws.com] > Sent: Sunday, January 16, 2011 6:54 PM > To: Tommy Pham > Cc: php-general@lists.php.net > Subject: Re: [PHP] [security] PHP has DoS vuln with large decimal points > > On 1/16/2011 4:18 PM, Tommy Pham wrote: > >> -Original Message- > >> From: Tommy Pham [mailto:tommy...@gmail.com] > >> Sent: Thursday, January 06, 2011 5:49 PM > >> To: 'Daevid Vincent' > >> Cc: 'php-general@lists.php.net' > >> Subject: RE: [PHP] [security] PHP has DoS vuln with large decimal > >> points > >> > >>> -Original Message- > >>> From: Daevid Vincent [mailto:dae...@daevid.com] > >>> Sent: Wednesday, January 05, 2011 11:36 AM > >>> To: php-general@lists.php.net > >>> Subject: [PHP] [security] PHP has DoS vuln with large decimal points > >>> > >>> The error in the way floating-point and double-precision numbers are > >>> handled sends 32-bit systems running Linux, Windows, and FreeBSD > >>> into an infinite loop that consumes 100 percent of their CPU's resources. > >>> Developers are still investigating, but they say the bug appears to > >>> affect versions 5.2 and 5.3 of PHP. They say it could be trivially > >>> exploited on many websites to cause them to crash by adding long > >> numbers to certain URLs. > >>> > >>> > >>> > >>> The crash is also triggered when the number is expressed without > >>> scientific notation, with 324 decimal places. > >>> > >>> Read on... > >>> > >>> http://www.theregister.co.uk/2011/01/04/weird_php_dos_vuln/ > >>> > >>> -- > >>> Daevid Vincent > >>> http://daevid.com > >>> > >>> There are only 11 types of people in this world. Those that think > >>> binary jokes are funny, those that don't, and those that don't know > > binary. > >>> > >> > >> "The size of a float is platform-dependent, although a maximum of > >> ~1.8e308 with a precision of roughly 14 decimal digits is a common > >> value (the 64 > > bit > >> IEEE format)." From [1]. The example given is clearly over the > >> limit > > within > >> the PHP core. > >> > >> This sounds like what I was mentioning before, in a different thread, > > about > >> URL hacking to induce buffer overflow. > >> > >> Regards, > >> Tommy > >> > >> [1] http://www.php.net/manual/en/language.types.float.php > > > > I found something really weird while coding a validator for floating > > protection protection. > > > > Case 1 - known DoS / PHP hangs in infinite loop: > > > > $value = '2.2250738585072011e-308'; > > var_dump(floatval($value)); > > > > Case 2 - works fine: > > > > $value = '2.2250738585072011e-307'; > > or > > $value = '2.2250738585072011e-309'; > > or > > $value = '2.225073858507201e-308'; > > > > var_dump(floatval($value)); > > > > I'd expect the '2.2250738585072011e-309' to hang also on my Win x64 with > PHP > > FastCGI. I haven't test it on *nix platform yet. Could someone please > > confirm this? > > > > Thanks, > > Tommy > > > > > > Seems to work fine for me. > > $ cat float.php > > echo "Example 1\n"; > $value = 2.2250738585072011e-307; > var_dump(floatval($value)); > var_dump($value); > > echo "Example 2\n"; > $value = 2.2250738585072011e-308; > var_dump(floatval($value)); > var_dump($value); > > echo "Example 3\n"; > $value = 2.2250738585072011e-309; > var_dump(floatval($value)); > var_dump($value); > > echo "Example 4\n"; > $value = 2.225073858507201e-308; > var_dump(floatval($value)); > var_dump($value); > > ?> > $ php -f float.php > Example 1 > float(2.2250738585072E-307) > float(2.2250738585072E-307) > Example 2 > float(2.2250738585072E-308) > float(2.2250738585072E-308) > Example 3 > float(2.2250738585072E-309) > float(2.2250738585072E-309) > Example 4 > float(2.2250738585072E-308) > float(2.2250738585072E-308) > > $ uname -a > OpenBSD serv0.cmsws.com 4.3 GENERIC#698 i386 $ php -v PHP 5.2.5 with > Suhosin-Patch 0.9.6.2 (cli) (built: Mar 11 2008 13:08:50) Copyright (c) 1997- > 2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend > Technologies > with Suhosin v0.9.20, Copyright (c) 2002-2006, by Hardened-PHP Project > > No infinite loop. I like my system... :) > > Jim Lucas Hi Jim, Thanks for the confirmation. It appears that the bug is with the official binary Windows distribution PHP 5.3.3 NTS and most likely with 5.3.3. I just upgrade to NTS 5.3.5 and works fine now. It also runs fine against unofficial PHP 5.2.5 x64 Windows ISAPI. Thanks, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] [security] PHP has DoS vuln with large decimal points
On Sun, Jan 16, 2011 at 21:00, Tommy Pham wrote:
>
> Here are the results after some further tests for the same platform:
>
> * max float value: 1.7976931348623E+308
> * min float value: 9.8813129168249E-324 <<
> floatval('1.00e-323') weird ...
>
> PHP wil hang when the value is between (inclusive)
>
> floatval('2.22507385850720102e-308') -
> floatval('2.22507385850720113e-308')
>
> I can't find the bug report for the issue @ bugs.php.net. Does anyone know
> if one is submitted? I should submit one? Sucribe to dev list and go from
> there?
If in doubt, file a bug. Worse comes to worst, it will be marked
as bogus or a duplicate. For security-related things, send them to
secur...@php.net, not to the General list. Again, if it's of no
concern, it will simply be ignored as bogus or already known.
--
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] [security] PHP has DoS vuln with large decimal points
On 1/16/2011 4:18 PM, Tommy Pham wrote: >> -Original Message- >> From: Tommy Pham [mailto:tommy...@gmail.com] >> Sent: Thursday, January 06, 2011 5:49 PM >> To: 'Daevid Vincent' >> Cc: 'php-general@lists.php.net' >> Subject: RE: [PHP] [security] PHP has DoS vuln with large decimal points >> >>> -Original Message- >>> From: Daevid Vincent [mailto:dae...@daevid.com] >>> Sent: Wednesday, January 05, 2011 11:36 AM >>> To: php-general@lists.php.net >>> Subject: [PHP] [security] PHP has DoS vuln with large decimal points >>> >>> The error in the way floating-point and double-precision numbers are >>> handled sends 32-bit systems running Linux, Windows, and FreeBSD into >>> an infinite loop that consumes 100 percent of their CPU's resources. >>> Developers are still investigating, but they say the bug appears to >>> affect versions 5.2 and 5.3 of PHP. They say it could be trivially >>> exploited on many websites to cause them to crash by adding long >> numbers to certain URLs. >>> >>> >>> >>> The crash is also triggered when the number is expressed without >>> scientific notation, with 324 decimal places. >>> >>> Read on... >>> >>> http://www.theregister.co.uk/2011/01/04/weird_php_dos_vuln/ >>> >>> -- >>> Daevid Vincent >>> http://daevid.com >>> >>> There are only 11 types of people in this world. Those that think >>> binary jokes are funny, those that don't, and those that don't know > binary. >>> >> >> "The size of a float is platform-dependent, although a maximum of ~1.8e308 >> with a precision of roughly 14 decimal digits is a common value (the 64 > bit >> IEEE format)." From [1]. The example given is clearly over the limit > within >> the PHP core. >> >> This sounds like what I was mentioning before, in a different thread, > about >> URL hacking to induce buffer overflow. >> >> Regards, >> Tommy >> >> [1] http://www.php.net/manual/en/language.types.float.php > > I found something really weird while coding a validator for floating > protection protection. > > Case 1 - known DoS / PHP hangs in infinite loop: > > $value = '2.2250738585072011e-308'; > var_dump(floatval($value)); > > Case 2 - works fine: > > $value = '2.2250738585072011e-307'; > or > $value = '2.2250738585072011e-309'; > or > $value = '2.225073858507201e-308'; > > var_dump(floatval($value)); > > I'd expect the '2.2250738585072011e-309' to hang also on my Win x64 with PHP > FastCGI. I haven't test it on *nix platform yet. Could someone please > confirm this? > > Thanks, > Tommy > > Seems to work fine for me. $ cat float.php $ php -f float.php Example 1 float(2.2250738585072E-307) float(2.2250738585072E-307) Example 2 float(2.2250738585072E-308) float(2.2250738585072E-308) Example 3 float(2.2250738585072E-309) float(2.2250738585072E-309) Example 4 float(2.2250738585072E-308) float(2.2250738585072E-308) $ uname -a OpenBSD serv0.cmsws.com 4.3 GENERIC#698 i386 $ php -v PHP 5.2.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 11 2008 13:08:50) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Suhosin v0.9.20, Copyright (c) 2002-2006, by Hardened-PHP Project No infinite loop. I like my system... :) Jim Lucas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] [security] PHP has DoS vuln with large decimal points
> -Original Message-
> From: Tommy Pham [mailto:tommy...@gmail.com]
> Sent: Sunday, January 16, 2011 4:18 PM
> To: 'php-general@lists.php.net'
> Subject: RE: [PHP] [security] PHP has DoS vuln with large decimal points
>
>
> I found something really weird while coding a validator for floating
> protection protection.
>
> Case 1 - known DoS / PHP hangs in infinite loop:
>
> $value = '2.2250738585072011e-308';
> var_dump(floatval($value));
>
> Case 2 - works fine:
>
> $value = '2.2250738585072011e-307';
> or
> $value = '2.2250738585072011e-309';
> or
> $value = '2.225073858507201e-308';
>
> var_dump(floatval($value));
>
> I'd expect the '2.2250738585072011e-309' to hang also on my Win x64 with
> PHP FastCGI. I haven't test it on *nix platform yet. Could someone
please
> confirm this?
>
> Thanks,
> Tommy
Here are the results after some further tests for the same platform:
* max float value: 1.7976931348623E+308
* min float value: 9.8813129168249E-324 <<
floatval('1.00e-323') weird ...
PHP wil hang when the value is between (inclusive)
floatval('2.22507385850720102e-308') -
floatval('2.22507385850720113e-308')
I can't find the bug report for the issue @ bugs.php.net. Does anyone know
if one is submitted? I should submit one? Sucribe to dev list and go from
there?
Thanks,
Tommy
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] [security] PHP has DoS vuln with large decimal points
> -Original Message- > From: Tommy Pham [mailto:tommy...@gmail.com] > Sent: Thursday, January 06, 2011 5:49 PM > To: 'Daevid Vincent' > Cc: 'php-general@lists.php.net' > Subject: RE: [PHP] [security] PHP has DoS vuln with large decimal points > > > -Original Message- > > From: Daevid Vincent [mailto:dae...@daevid.com] > > Sent: Wednesday, January 05, 2011 11:36 AM > > To: php-general@lists.php.net > > Subject: [PHP] [security] PHP has DoS vuln with large decimal points > > > > The error in the way floating-point and double-precision numbers are > > handled sends 32-bit systems running Linux, Windows, and FreeBSD into > > an infinite loop that consumes 100 percent of their CPU's resources. > > Developers are still investigating, but they say the bug appears to > > affect versions 5.2 and 5.3 of PHP. They say it could be trivially > > exploited on many websites to cause them to crash by adding long > numbers to certain URLs. > > > > > > > > The crash is also triggered when the number is expressed without > > scientific notation, with 324 decimal places. > > > > Read on... > > > > http://www.theregister.co.uk/2011/01/04/weird_php_dos_vuln/ > > > > -- > > Daevid Vincent > > http://daevid.com > > > > There are only 11 types of people in this world. Those that think > > binary jokes are funny, those that don't, and those that don't know binary. > > > > "The size of a float is platform-dependent, although a maximum of ~1.8e308 > with a precision of roughly 14 decimal digits is a common value (the 64 bit > IEEE format)." From [1]. The example given is clearly over the limit within > the PHP core. > > This sounds like what I was mentioning before, in a different thread, about > URL hacking to induce buffer overflow. > > Regards, > Tommy > > [1] http://www.php.net/manual/en/language.types.float.php I found something really weird while coding a validator for floating protection protection. Case 1 - known DoS / PHP hangs in infinite loop: $value = '2.2250738585072011e-308'; var_dump(floatval($value)); Case 2 - works fine: $value = '2.2250738585072011e-307'; or $value = '2.2250738585072011e-309'; or $value = '2.225073858507201e-308'; var_dump(floatval($value)); I'd expect the '2.2250738585072011e-309' to hang also on my Win x64 with PHP FastCGI. I haven't test it on *nix platform yet. Could someone please confirm this? Thanks, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] [security] PHP has DoS vuln with large decimal points
> -Original Message- > From: Daevid Vincent [mailto:dae...@daevid.com] > Sent: Wednesday, January 05, 2011 11:36 AM > To: php-general@lists.php.net > Subject: [PHP] [security] PHP has DoS vuln with large decimal points > > The error in the way floating-point and double-precision numbers are > handled sends 32-bit systems running Linux, Windows, and FreeBSD into an > infinite loop that consumes 100 percent of their CPU's resources. > Developers are still investigating, but they say the bug appears to affect > versions 5.2 and 5.3 of PHP. They say it could be trivially exploited on many > websites to cause them to crash by adding long numbers to certain URLs. > > > > The crash is also triggered when the number is expressed without scientific > notation, with 324 decimal places. > > Read on... > > http://www.theregister.co.uk/2011/01/04/weird_php_dos_vuln/ > > -- > Daevid Vincent > http://daevid.com > > There are only 11 types of people in this world. Those that think binary > jokes are funny, those that don't, and those that don't know binary. > "The size of a float is platform-dependent, although a maximum of ~1.8e308 with a precision of roughly 14 decimal digits is a common value (the 64 bit IEEE format)." From [1]. The example given is clearly over the limit within the PHP core. This sounds like what I was mentioning before, in a different thread, about URL hacking to induce buffer overflow. Regards, Tommy [1] http://www.php.net/manual/en/language.types.float.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Issue
Yes and scrubbing the input to ensure the field used for this URL
rejects certain characters or does sanity checking on it would also be
another suggestion. Turning this off would fix remote include
requests. But still need to check for people requesting local files.
Should never take user input and put it directly into include or shell
execs or anything.
On Jun 8, 2010, at 11:55 AM, "David Stoltz" wrote:
allow_url_include is (or should be) disabled by default.
http://us2.php.net/manual/en/filesystem.configuration.php#ini.allow-url-
include
I can't think of one good reason to ever enable this, it would be a
security issue no matter how you slice it...
-Original Message-
From: Igor Escobar [mailto:titiolin...@gmail.com]
Sent: Tuesday, June 08, 2010 10:11 AM
To: richg...@gmail.com
Cc:
Subject: Re: [PHP] Security Issue
Hey Richard,
I'll find more about this parameter allow_url_include, thank you!
Regards,
Igor Escobar
Systems Analyst & Interface Designer
+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar (twitter)
On Mon, Jun 7, 2010 at 5:26 PM, richard gray
wrote:
On 07/06/2010 20:00, Igor Escobar wrote:
PHP Injection is the technical name given to a security hole in PHP
applications. When this gap there is a hacker can do with an
external
code
that is interpreted as an inner code as if the code included was
more
a
part
of the script.
// my code...
// my code...
include ('http:///externalhackscript.txt');
//my code...
//my code..
can you not switch off remote file includes in php.ini?
This will stop include/require from a remote host..
i.e. /allow_url_include = Off in php.ini
HTH
Rich
/
--
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] Security Issue
allow_url_include is (or should be) disabled by default.
http://us2.php.net/manual/en/filesystem.configuration.php#ini.allow-url-
include
I can't think of one good reason to ever enable this, it would be a
security issue no matter how you slice it...
-Original Message-
From: Igor Escobar [mailto:titiolin...@gmail.com]
Sent: Tuesday, June 08, 2010 10:11 AM
To: richg...@gmail.com
Cc:
Subject: Re: [PHP] Security Issue
Hey Richard,
I'll find more about this parameter allow_url_include, thank you!
Regards,
Igor Escobar
Systems Analyst & Interface Designer
+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar (twitter)
On Mon, Jun 7, 2010 at 5:26 PM, richard gray wrote:
> On 07/06/2010 20:00, Igor Escobar wrote:
>
>> PHP Injection is the technical name given to a security hole in PHP
>> applications. When this gap there is a hacker can do with an external
code
>> that is interpreted as an inner code as if the code included was more
a
>> part
>> of the script.
>>
>> // my code...
>> // my code...
>> include ('http:///externalhackscript.txt');
>> //my code...
>> //my code..
>>
> can you not switch off remote file includes in php.ini?
> This will stop include/require from a remote host..
> i.e. /allow_url_include = Off in php.ini
>
> HTH
> Rich
> /
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Issue
Hey Richard,
I'll find more about this parameter allow_url_include, thank you!
Regards,
Igor Escobar
Systems Analyst & Interface Designer
+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar (twitter)
On Mon, Jun 7, 2010 at 5:26 PM, richard gray wrote:
> On 07/06/2010 20:00, Igor Escobar wrote:
>
>> PHP Injection is the technical name given to a security hole in PHP
>> applications. When this gap there is a hacker can do with an external code
>> that is interpreted as an inner code as if the code included was more a
>> part
>> of the script.
>>
>> // my code...
>> // my code...
>> include ('http:///externalhackscript.txt');
>> //my code...
>> //my code..
>>
> can you not switch off remote file includes in php.ini?
> This will stop include/require from a remote host..
> i.e. /allow_url_include = Off in php.ini
>
> HTH
> Rich
> /
>
Re: [PHP] Security Issue
Are you running the latest version of PHP? If not you should check for PHP vulnerabilities for the version that you have installed. You should also check your OS and web server software for security holes. On Mon, Jun 7, 2010 at 7:54 AM, Igor Escobar wrote: > Hi Folks! > > The portal for which I work is suffering constant attacks that I feel that > is PHP Injection. Somehow the hacker is getting to change the cache files > that our system generates. Concatenating the HTML file with another that > have an iframe to a malicious JAR file. Do you have any suggestions to > prevent this action? The hacker has no access to our file system, he is > imputing the code through some security hole. The problem is that the > portal > is very big and has lots and lots partners hosted on our estructure > structure. We are failing to identify the focus of this attacks. > > Any ideas? > > > Regards, > Igor Escobar > Systems Analyst & Interface Designer > > + http://blog.igorescobar.com > + http://www.igorescobar.com > + @igorescobar (twitter) >
Re: [PHP] Security Issue
On 07/06/2010 20:00, Igor Escobar wrote:
PHP Injection is the technical name given to a security hole in PHP
applications. When this gap there is a hacker can do with an external code
that is interpreted as an inner code as if the code included was more a part
of the script.
// my code...
// my code...
include ('http:///externalhackscript.txt');
//my code...
//my code..
can you not switch off remote file includes in php.ini?
This will stop include/require from a remote host..
i.e. /allow_url_include = Off in php.ini
HTH
Rich
/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Issue
From: Ashley Sheridan > On Mon, 2010-06-07 at 15:00 -0300, Igor Escobar wrote: > >> PHP Injection is the technical name given to a security hole in PHP >> applications. When this gap there is a hacker can do with an external >> code that is interpreted as an inner code as if the code included was >> more a part of the script. > > That data is still coming from somewhere, so is still badly sanitised > data either coming from a form or a URL. You really should go over all > the code to find these and root them out, which is a mammoth task. To > narrow it down, those access logs I mentioned before will help. I think > there are ways you can automatically detect security holes in your > software, but if none of your user data is sanitised correctly, then > virtually everything is a potential security hole. You need to narrow your search down a bit. Are there corrupted files on the server? Who has write privileges for those files and directories? Are they tracked via a content management system? Who last wrote to them? Can you further restrict who is allowed to write into those files and directories? Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Issue
On Mon, 2010-06-07 at 15:00 -0300, Igor Escobar wrote:
> PHP Injection is the technical name given to a security hole in PHP
> applications. When this gap there is a hacker can do with an external
> code that is interpreted as an inner code as if the code included was
> more a part of the script.
>
>
>
> // my code...
> // my code...
> include ('http:///externalhackscript.txt');
> //my code...
> //my code..
>
>
> I know how to fix that too. The problem is: WHERE I HAVE TO FIX THAT.
>
>
> Got it?
>
>
>
>
>
> Regards,
> Igor Escobar
> Systems Analyst & Interface Designer
>
> + http://blog.igorescobar.com
> + http://www.igorescobar.com
> + @igorescobar (twitter)
>
>
>
>
>
>
> On Mon, Jun 7, 2010 at 2:48 PM, Ashley Sheridan
> wrote:
>
>
> On Mon, 2010-06-07 at 14:42 -0300, Igor Escobar wrote:
>
> > It's not a SQL Injection or XSS problem, Michael.
> >
> > It's a PHP Injection problem. I know how fix that but the
> web site is very
> > very huge, have lots and lots of partners and i'm have a bug
> difficult do
> > identify the focus of the problem.
> >
> > Got it?
> >
> >
> > Regards,
> > Igor Escobar
> > Systems Analyst & Interface Designer
> >
> > + http://blog.igorescobar.com
> > + http://www.igorescobar.com
> > + @igorescobar (twitter)
> >
> >
> >
> >
> >
> > On Mon, Jun 7, 2010 at 2:38 PM, Michael Shadle
> wrote:
> >
> > > It's not that bad.
> > >
> > > Use filter functions and sanity checks for input.
> > >
> > > Use htmlspecialchars() basically on output.
> > >
> > > That should take care of basically everything.
> > >
> > >
> > > On Jun 7, 2010, at 6:16 AM, Igor Escobar
> wrote:
> > >
> > > This was my fear.
> > >>
> > >> Regards,
> > >> Igor Escobar
> > >> Systems Analyst & Interface Designer
> > >>
> > >> + http://blog.igorescobar.com
> > >> + http://www.igorescobar.com
> > >> + @igorescobar (twitter)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind
>
> > >> wrote:
> > >>
> > >> On 7 June 2010 14:54, Igor Escobar
> wrote:
> > >>>
> > Hi Folks!
> >
> > The portal for which I work is suffering constant
> attacks that I feel
> >
> > >>> that
> > >>>
> > is PHP Injection. Somehow the hacker is getting to
> change the cache
> > files
> > that our system generates. Concatenating the HTML file
> with another that
> > have an iframe to a malicious JAR file. Do you have any
> suggestions to
> > prevent this action? The hacker has no access to our
> file system, he is
> > imputing the code through some security hole. The
> problem is that the
> >
> > >>> portal
> > >>>
> > is very big and has lots and lots partners hosted on
> our estructure
> > structure. We are failing to identify the focus of this
> attacks.
> >
> > Any ideas?
> >
> >
> > >>> Check all user input + upload: make sure that whatever
> comes from the
> > >>> user is validated. Then check all output: make sure that
> everythin
> > >>> output is escaped properly. Yes, it's an enormous task,
> but there's no
> > >>> way around it.
> > >>>
> > >>> Regards
> > >>> Peter
> > >>>
> > >>> --
> > >>>
> > >>> WWW: http://plphp.dk / http://plind.dk
> > >>> LinkedIn: http://www.linkedin.com/in/plind
> > >>> BeWelcome/Couchsurfing: Fake51
> > >>> Twitter: http://twitter.com/kafe15
> > >>>
> > >>>
> > >>>
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
>
>
>
>
> What do you mean it's a PHP injection? PHP is all on the
> server, and the
> only way to get at that if you don't have direct access to the
> server
> (which you've said isn't possible as the passwords, etc are
> all fine)
> then the bad data is coming from either a form or another area
> where
> user data is expected. This data might be as simple as
> unsanitised URL
> variables that are intended to fetch a blog entry, to form
>
Re: [PHP] Security Issue
I disagree and this kind of approach could be appropriate if you walk your input globals and apply some sanity checks and appropriate filtering you could fix the issue. On Jun 7, 2010, at 10:52 AM, Igor Escobar wrote: I think we're getting off topic here folks... Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 2:51 PM, Ashley Sheridan > wrote: On Mon, 2010-06-07 at 10:48 -0700, Michael Shadle wrote: Oh yeah. I do more than just intval() I make sure they didn't feed me anything BUT numeric text first. I do sanity check before type forcing :) I use garbage in garbage out. So I take what is given to me and yes I escape if before the db of course as well, and then encode on output. On Jun 7, 2010, at 10:45 AM, Ashley Sheridan wrote: > On Mon, 2010-06-07 at 10:38 -0700, Michael Shadle wrote: >> >> It's not that bad. >> >> Use filter functions and sanity checks for input. >> >> Use htmlspecialchars() basically on output. >> >> That should take care of basically everything. >> >> On Jun 7, 2010, at 6:16 AM, Igor Escobar >> wrote: >> >> > This was my fear. >> > >> > Regards, >> > Igor Escobar >> > Systems Analyst & Interface Designer >> > >> > + http://blog.igorescobar.com >> > + http://www.igorescobar.com >> > + @igorescobar (twitter) >> > >> > >> > >> > >> > >> > On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind >> >> > wrote: >> > >> >> On 7 June 2010 14:54, Igor Escobar wrote: >> >>> Hi Folks! >> >>> >> >>> The portal for which I work is suffering constant attacks that I >> >>> feel >> >> that >> >>> is PHP Injection. Somehow the hacker is getting to change the >> >>> cache files >> >>> that our system generates. Concatenating the HTML file with >> >>> another that >> >>> have an iframe to a malicious JAR file. Do you have any >> >>> suggestions to >> >>> prevent this action? The hacker has no access to our file system, >> >>> he is >> >>> imputing the code through some security hole. The problem is that >> >>> the >> >> portal >> >>> is very big and has lots and lots partners hosted on our >> estructure >> >>> structure. We are failing to identify the focus of this attacks. >> >>> >> >>> Any ideas? >> >>> >> >> >> >> Check all user input + upload: make sure that whatever comes >> from the >> >> user is validated. Then check all output: make sure that everythin >> >> output is escaped properly. Yes, it's an enormous task, but >> there's >> >> no >> >> way around it. >> >> >> >> Regards >> >> Peter >> >> >> >> -- >> >> >> >> WWW: http://plphp.dk / http://plind.dk >> >> LinkedIn: http://www.linkedin.com/in/plind >> >> BeWelcome/Couchsurfing: Fake51 >> >> Twitter: http://twitter.com/kafe15 >> >> >> >> >> > > htmlspecialchars() is really only good for user input that you are > outputting to the browser. For inserting data into a database, use > mysql_real_escape_string(). I find it's good to think carefully > about what sort of data I expect and sanitise it accordingly. If I > want a numerical value, I use intval($_GET['var']) or floatval(). > For things like small text box elements, regex's work well depending > on the data. For data from select lists of checkboxes, make sure the > value given is within a list of pre-determined values you have. > Basically, nothing from the user should be trusted at all, ever. > > As soon as you let go of that trust in the good honesty of people > you'll do fine ;) > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > Why waste time validating an integer value when intval() will do that for you? Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Security Issue
I'm totally agree with you Ash,
I came up here to ask you guys some for light. Anything to well me to track
that M%$#% F#$CK#$# and discover from where he's attacking.
Regards,
Igor Escobar
Systems Analyst & Interface Designer
+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar (twitter)
On Mon, Jun 7, 2010 at 3:06 PM, Ashley Sheridan
wrote:
> On Mon, 2010-06-07 at 15:00 -0300, Igor Escobar wrote:
>
> PHP Injection is the technical name given to a security hole in PHP
> applications. When this gap there is a hacker can do with an external code
> that is interpreted as an inner code as if the code included was more a part
> of the script.
>
>
>
> // my code...
>
> // my code...
>
> include ('http:///externalhackscript.txt');
>
> //my code...
>
> //my code..
>
>
>
> I know how to fix that too. The problem is: WHERE I HAVE TO FIX THAT.
>
>
>
> Got it?
>
>
>
>
>
> Regards,
> Igor Escobar
> Systems Analyst & Interface Designer
>
> + http://blog.igorescobar.com
> + http://www.igorescobar.com
> + @igorescobar (twitter)
>
>
>
>
>
> On Mon, Jun 7, 2010 at 2:48 PM, Ashley Sheridan
> wrote:
>
>
> On Mon, 2010-06-07 at 14:42 -0300, Igor Escobar wrote:
>
> > It's not a SQL Injection or XSS problem, Michael.
> >
> > It's a PHP Injection problem. I know how fix that but the web site is
> very
> > very huge, have lots and lots of partners and i'm have a bug difficult do
> > identify the focus of the problem.
> >
> > Got it?
> >
> >
> > Regards,
> > Igor Escobar
> > Systems Analyst & Interface Designer
> >
> > + http://blog.igorescobar.com
> > + http://www.igorescobar.com
> > + @igorescobar (twitter)
> >
> >
> >
> >
> >
> > On Mon, Jun 7, 2010 at 2:38 PM, Michael Shadle
> wrote:
> >
> > > It's not that bad.
> > >
> > > Use filter functions and sanity checks for input.
> > >
> > > Use htmlspecialchars() basically on output.
> > >
> > > That should take care of basically everything.
> > >
> > >
> > > On Jun 7, 2010, at 6:16 AM, Igor Escobar
> wrote:
> > >
> > > This was my fear.
> > >>
> > >> Regards,
> > >> Igor Escobar
> > >> Systems Analyst & Interface Designer
> > >>
> > >> + http://blog.igorescobar.com
> > >> + http://www.igorescobar.com
> > >> + @igorescobar (twitter)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind
> > >> wrote:
> > >>
> > >> On 7 June 2010 14:54, Igor Escobar wrote:
> > >>>
> > Hi Folks!
> >
> > The portal for which I work is suffering constant attacks that I
> feel
> >
> > >>> that
> > >>>
> > is PHP Injection. Somehow the hacker is getting to change the cache
> > files
> > that our system generates. Concatenating the HTML file with another
> that
> > have an iframe to a malicious JAR file. Do you have any suggestions
> to
> > prevent this action? The hacker has no access to our file system, he
> is
> > imputing the code through some security hole. The problem is that
> the
> >
> > >>> portal
> > >>>
> > is very big and has lots and lots partners hosted on our estructure
> > structure. We are failing to identify the focus of this attacks.
> >
> > Any ideas?
> >
> >
> > >>> Check all user input + upload: make sure that whatever comes from the
> > >>> user is validated. Then check all output: make sure that everythin
> > >>> output is escaped properly. Yes, it's an enormous task, but there's
> no
> > >>> way around it.
> > >>>
> > >>> Regards
> > >>> Peter
> > >>>
> > >>> --
> > >>>
> > >>> WWW: http://plphp.dk / http://plind.dk
> > >>> LinkedIn: http://www.linkedin.com/in/plind
> > >>> BeWelcome/Couchsurfing: Fake51
> > >>> Twitter: http://twitter.com/kafe15
> > >>>
> > >>>
> > >>>
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
>
>
>
> What do you mean it's a PHP injection? PHP is all on the server, and the
> only way to get at that if you don't have direct access to the server
> (which you've said isn't possible as the passwords, etc are all fine)
> then the bad data is coming from either a form or another area where
> user data is expected. This data might be as simple as unsanitised URL
> variables that are intended to fetch a blog entry, to form data sent in
> a registration page.
>
> All data coming from the user is bad until proven otherwise.
>
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
>
>
> That data is still coming from somewhere, so is still badly sanitised data
> either coming from a form or a URL. You really should go over all the code
> to find these and root them out, which is a mammoth task. To narrow it down,
> those access logs I mentioned before will help. I think there are ways you
> can automatically detect security holes in your software, but if none of
> your user data is sanitised correctly, then virtually everything is a
> potential security hole.
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.c
Re: [PHP] Security Issue
PHP Injection is the technical name given to a security hole in PHP
applications. When this gap there is a hacker can do with an external code
that is interpreted as an inner code as if the code included was more a part
of the script.
// my code...
// my code...
include ('http:///externalhackscript.txt');
//my code...
//my code..
I know how to fix that too. The problem is: WHERE I HAVE TO FIX THAT.
Got it?
Regards,
Igor Escobar
Systems Analyst & Interface Designer
+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar (twitter)
On Mon, Jun 7, 2010 at 2:48 PM, Ashley Sheridan
wrote:
> On Mon, 2010-06-07 at 14:42 -0300, Igor Escobar wrote:
>
> > It's not a SQL Injection or XSS problem, Michael.
> >
> > It's a PHP Injection problem. I know how fix that but the web site is
> very
> > very huge, have lots and lots of partners and i'm have a bug difficult do
> > identify the focus of the problem.
> >
> > Got it?
> >
> >
> > Regards,
> > Igor Escobar
> > Systems Analyst & Interface Designer
> >
> > + http://blog.igorescobar.com
> > + http://www.igorescobar.com
> > + @igorescobar (twitter)
> >
> >
> >
> >
> >
> > On Mon, Jun 7, 2010 at 2:38 PM, Michael Shadle
> wrote:
> >
> > > It's not that bad.
> > >
> > > Use filter functions and sanity checks for input.
> > >
> > > Use htmlspecialchars() basically on output.
> > >
> > > That should take care of basically everything.
> > >
> > >
> > > On Jun 7, 2010, at 6:16 AM, Igor Escobar
> wrote:
> > >
> > > This was my fear.
> > >>
> > >> Regards,
> > >> Igor Escobar
> > >> Systems Analyst & Interface Designer
> > >>
> > >> + http://blog.igorescobar.com
> > >> + http://www.igorescobar.com
> > >> + @igorescobar (twitter)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind
> > >> wrote:
> > >>
> > >> On 7 June 2010 14:54, Igor Escobar wrote:
> > >>>
> > Hi Folks!
> >
> > The portal for which I work is suffering constant attacks that I
> feel
> >
> > >>> that
> > >>>
> > is PHP Injection. Somehow the hacker is getting to change the cache
> > files
> > that our system generates. Concatenating the HTML file with another
> that
> > have an iframe to a malicious JAR file. Do you have any suggestions
> to
> > prevent this action? The hacker has no access to our file system, he
> is
> > imputing the code through some security hole. The problem is that
> the
> >
> > >>> portal
> > >>>
> > is very big and has lots and lots partners hosted on our estructure
> > structure. We are failing to identify the focus of this attacks.
> >
> > Any ideas?
> >
> >
> > >>> Check all user input + upload: make sure that whatever comes from the
> > >>> user is validated. Then check all output: make sure that everythin
> > >>> output is escaped properly. Yes, it's an enormous task, but there's
> no
> > >>> way around it.
> > >>>
> > >>> Regards
> > >>> Peter
> > >>>
> > >>> --
> > >>>
> > >>> WWW: http://plphp.dk / http://plind.dk
> > >>> LinkedIn: http://www.linkedin.com/in/plind
> > >>> BeWelcome/Couchsurfing: Fake51
> > >>> Twitter: http://twitter.com/kafe15
> > >>>
> > >>>
> > >>>
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
>
>
> What do you mean it's a PHP injection? PHP is all on the server, and the
> only way to get at that if you don't have direct access to the server
> (which you've said isn't possible as the passwords, etc are all fine)
> then the bad data is coming from either a form or another area where
> user data is expected. This data might be as simple as unsanitised URL
> variables that are intended to fetch a blog entry, to form data sent in
> a registration page.
>
> All data coming from the user is bad until proven otherwise.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
Re: [PHP] Security Issue
Because that only typecasts it. It's safe but it isn't what the user actually entered. This way I can actually determine if the user put in "123abc" and reject it, not accept it and keep the "123" silently for example. Same with floats. You may or may not consider a negative number acceptable, or with ints and floats 0 might not be acceptable too. So it's some analysis before intval/floatval/etc. I want to return to the user with a rejection notice so they literally get what they gave me (assuming it passes the sanity check) - it's not just simple silently typecasting and giving them something they didn't give me. And I meant to say "garbage in, garbage out*" * properly encoded or sanitized of course :) On Jun 7, 2010, at 10:51 AM, Ashley Sheridan wrote: Why waste time validating an integer value when intval() will do that for you? Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Security Issue
You could do generic things to modify the $_GET and other superglobal arrays. For example if you wanted to implement magic quote yourself have a recursive function (I'd paste one but I'm on my phone) but something akin to this: $_GET = your_function_name($_GET); An idea for you might be to look for / or .. and reject or sanitize that in some fashion. Really hard to speak on what would safely work across the website globally (you could also just modify those specific array indexes of $_GET that have filenames or something the cache uses) Hope that makes sense. iPhones aren't the easiest to explain (or bottom post) On Jun 7, 2010, at 10:42 AM, Igor Escobar wrote: It's not a SQL Injection or XSS problem, Michael. It's a PHP Injection problem. I know how fix that but the web site is very very huge, have lots and lots of partners and i'm have a bug difficult do identify the focus of the problem. Got it? Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 2:38 PM, Michael Shadle wrote: It's not that bad. Use filter functions and sanity checks for input. Use htmlspecialchars() basically on output. That should take care of basically everything. On Jun 7, 2010, at 6:16 AM, Igor Escobar wrote: This was my fear. Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind wrote: On 7 June 2010 14:54, Igor Escobar wrote: Hi Folks! The portal for which I work is suffering constant attacks that I feel that is PHP Injection. Somehow the hacker is getting to change the cache files that our system generates. Concatenating the HTML file with another that have an iframe to a malicious JAR file. Do you have any suggestions to prevent this action? The hacker has no access to our file system, he is imputing the code through some security hole. The problem is that the portal is very big and has lots and lots partners hosted on our estructure structure. We are failing to identify the focus of this attacks. Any ideas? Check all user input + upload: make sure that whatever comes from the user is validated. Then check all output: make sure that everythin output is escaped properly. Yes, it's an enormous task, but there's no way around it. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Issue
I think we're getting off topic here folks... Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 2:51 PM, Ashley Sheridan wrote: > On Mon, 2010-06-07 at 10:48 -0700, Michael Shadle wrote: > > Oh yeah. I do more than just intval() I make sure they didn't feed me > anything BUT numeric text first. I do sanity check before type > forcing :) > > I use garbage in garbage out. So I take what is given to me and yes I > escape if before the db of course as well, and then encode on output. > > On Jun 7, 2010, at 10:45 AM, Ashley Sheridan > wrote: > > > On Mon, 2010-06-07 at 10:38 -0700, Michael Shadle wrote: > >> > >> It's not that bad. > >> > >> Use filter functions and sanity checks for input. > >> > >> Use htmlspecialchars() basically on output. > >> > >> That should take care of basically everything. > >> > >> On Jun 7, 2010, at 6:16 AM, Igor Escobar > >> wrote: > >> > >> > This was my fear. > >> > > >> > Regards, > >> > Igor Escobar > >> > Systems Analyst & Interface Designer > >> > > >> > + http://blog.igorescobar.com > >> > + http://www.igorescobar.com > >> > + @igorescobar (twitter) > >> > > >> > > >> > > >> > > >> > > >> > On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind > >> > >> > wrote: > >> > > >> >> On 7 June 2010 14:54, Igor Escobar wrote: > >> >>> Hi Folks! > >> >>> > >> >>> The portal for which I work is suffering constant attacks that I > >> >>> feel > >> >> that > >> >>> is PHP Injection. Somehow the hacker is getting to change the > >> >>> cache files > >> >>> that our system generates. Concatenating the HTML file with > >> >>> another that > >> >>> have an iframe to a malicious JAR file. Do you have any > >> >>> suggestions to > >> >>> prevent this action? The hacker has no access to our file system, > >> >>> he is > >> >>> imputing the code through some security hole. The problem is that > >> >>> the > >> >> portal > >> >>> is very big and has lots and lots partners hosted on our > >> estructure > >> >>> structure. We are failing to identify the focus of this attacks. > >> >>> > >> >>> Any ideas? > >> >>> > >> >> > >> >> Check all user input + upload: make sure that whatever comes > >> from the > >> >> user is validated. Then check all output: make sure that everythin > >> >> output is escaped properly. Yes, it's an enormous task, but > >> there's > >> >> no > >> >> way around it. > >> >> > >> >> Regards > >> >> Peter > >> >> > >> >> -- > >> >> > >> >> WWW: http://plphp.dk / http://plind.dk > >> >> LinkedIn: http://www.linkedin.com/in/plind > >> >> BeWelcome/Couchsurfing: Fake51 > >> >> Twitter: http://twitter.com/kafe15 > >> >> > >> >> > >> > > > > htmlspecialchars() is really only good for user input that you are > > outputting to the browser. For inserting data into a database, use > > mysql_real_escape_string(). I find it's good to think carefully > > about what sort of data I expect and sanitise it accordingly. If I > > want a numerical value, I use intval($_GET['var']) or floatval(). > > For things like small text box elements, regex's work well depending > > on the data. For data from select lists of checkboxes, make sure the > > value given is within a list of pre-determined values you have. > > Basically, nothing from the user should be trusted at all, ever. > > > > As soon as you let go of that trust in the good honesty of people > > you'll do fine ;) > > > > Thanks, > > Ash > > http://www.ashleysheridan.co.uk > > > > > > > Why waste time validating an integer value when intval() will do that for > you? > > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > >
Re: [PHP] Security Issue
On Mon, 2010-06-07 at 10:48 -0700, Michael Shadle wrote: > Oh yeah. I do more than just intval() I make sure they didn't feed me > anything BUT numeric text first. I do sanity check before type > forcing :) > > I use garbage in garbage out. So I take what is given to me and yes I > escape if before the db of course as well, and then encode on output. > > On Jun 7, 2010, at 10:45 AM, Ashley Sheridan > wrote: > > > On Mon, 2010-06-07 at 10:38 -0700, Michael Shadle wrote: > >> > >> It's not that bad. > >> > >> Use filter functions and sanity checks for input. > >> > >> Use htmlspecialchars() basically on output. > >> > >> That should take care of basically everything. > >> > >> On Jun 7, 2010, at 6:16 AM, Igor Escobar > >> wrote: > >> > >> > This was my fear. > >> > > >> > Regards, > >> > Igor Escobar > >> > Systems Analyst & Interface Designer > >> > > >> > + http://blog.igorescobar.com > >> > + http://www.igorescobar.com > >> > + @igorescobar (twitter) > >> > > >> > > >> > > >> > > >> > > >> > On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind > >> > >> > wrote: > >> > > >> >> On 7 June 2010 14:54, Igor Escobar wrote: > >> >>> Hi Folks! > >> >>> > >> >>> The portal for which I work is suffering constant attacks that I > >> >>> feel > >> >> that > >> >>> is PHP Injection. Somehow the hacker is getting to change the > >> >>> cache files > >> >>> that our system generates. Concatenating the HTML file with > >> >>> another that > >> >>> have an iframe to a malicious JAR file. Do you have any > >> >>> suggestions to > >> >>> prevent this action? The hacker has no access to our file system, > >> >>> he is > >> >>> imputing the code through some security hole. The problem is that > >> >>> the > >> >> portal > >> >>> is very big and has lots and lots partners hosted on our > >> estructure > >> >>> structure. We are failing to identify the focus of this attacks. > >> >>> > >> >>> Any ideas? > >> >>> > >> >> > >> >> Check all user input + upload: make sure that whatever comes > >> from the > >> >> user is validated. Then check all output: make sure that everythin > >> >> output is escaped properly. Yes, it's an enormous task, but > >> there's > >> >> no > >> >> way around it. > >> >> > >> >> Regards > >> >> Peter > >> >> > >> >> -- > >> >> > >> >> WWW: http://plphp.dk / http://plind.dk > >> >> LinkedIn: http://www.linkedin.com/in/plind > >> >> BeWelcome/Couchsurfing: Fake51 > >> >> Twitter: http://twitter.com/kafe15 > >> >> > >> >> > >> > > > > htmlspecialchars() is really only good for user input that you are > > outputting to the browser. For inserting data into a database, use > > mysql_real_escape_string(). I find it's good to think carefully > > about what sort of data I expect and sanitise it accordingly. If I > > want a numerical value, I use intval($_GET['var']) or floatval(). > > For things like small text box elements, regex's work well depending > > on the data. For data from select lists of checkboxes, make sure the > > value given is within a list of pre-determined values you have. > > Basically, nothing from the user should be trusted at all, ever. > > > > As soon as you let go of that trust in the good honesty of people > > you'll do fine ;) > > > > Thanks, > > Ash > > http://www.ashleysheridan.co.uk > > > > Why waste time validating an integer value when intval() will do that for you? Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Security Issue
On Mon, 2010-06-07 at 14:42 -0300, Igor Escobar wrote: > It's not a SQL Injection or XSS problem, Michael. > > It's a PHP Injection problem. I know how fix that but the web site is very > very huge, have lots and lots of partners and i'm have a bug difficult do > identify the focus of the problem. > > Got it? > > > Regards, > Igor Escobar > Systems Analyst & Interface Designer > > + http://blog.igorescobar.com > + http://www.igorescobar.com > + @igorescobar (twitter) > > > > > > On Mon, Jun 7, 2010 at 2:38 PM, Michael Shadle wrote: > > > It's not that bad. > > > > Use filter functions and sanity checks for input. > > > > Use htmlspecialchars() basically on output. > > > > That should take care of basically everything. > > > > > > On Jun 7, 2010, at 6:16 AM, Igor Escobar wrote: > > > > This was my fear. > >> > >> Regards, > >> Igor Escobar > >> Systems Analyst & Interface Designer > >> > >> + http://blog.igorescobar.com > >> + http://www.igorescobar.com > >> + @igorescobar (twitter) > >> > >> > >> > >> > >> > >> On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind > >> wrote: > >> > >> On 7 June 2010 14:54, Igor Escobar wrote: > >>> > Hi Folks! > > The portal for which I work is suffering constant attacks that I feel > > >>> that > >>> > is PHP Injection. Somehow the hacker is getting to change the cache > files > that our system generates. Concatenating the HTML file with another that > have an iframe to a malicious JAR file. Do you have any suggestions to > prevent this action? The hacker has no access to our file system, he is > imputing the code through some security hole. The problem is that the > > >>> portal > >>> > is very big and has lots and lots partners hosted on our estructure > structure. We are failing to identify the focus of this attacks. > > Any ideas? > > > >>> Check all user input + upload: make sure that whatever comes from the > >>> user is validated. Then check all output: make sure that everythin > >>> output is escaped properly. Yes, it's an enormous task, but there's no > >>> way around it. > >>> > >>> Regards > >>> Peter > >>> > >>> -- > >>> > >>> WWW: http://plphp.dk / http://plind.dk > >>> LinkedIn: http://www.linkedin.com/in/plind > >>> BeWelcome/Couchsurfing: Fake51 > >>> Twitter: http://twitter.com/kafe15 > >>> > >>> > >>> > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > What do you mean it's a PHP injection? PHP is all on the server, and the only way to get at that if you don't have direct access to the server (which you've said isn't possible as the passwords, etc are all fine) then the bad data is coming from either a form or another area where user data is expected. This data might be as simple as unsanitised URL variables that are intended to fetch a blog entry, to form data sent in a registration page. All data coming from the user is bad until proven otherwise. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Security Issue
Oh yeah. I do more than just intval() I make sure they didn't feed me anything BUT numeric text first. I do sanity check before type forcing :) I use garbage in garbage out. So I take what is given to me and yes I escape if before the db of course as well, and then encode on output. On Jun 7, 2010, at 10:45 AM, Ashley Sheridan wrote: On Mon, 2010-06-07 at 10:38 -0700, Michael Shadle wrote: It's not that bad. Use filter functions and sanity checks for input. Use htmlspecialchars() basically on output. That should take care of basically everything. On Jun 7, 2010, at 6:16 AM, Igor Escobar wrote: > This was my fear. > > Regards, > Igor Escobar > Systems Analyst & Interface Designer > > + http://blog.igorescobar.com > + http://www.igorescobar.com > + @igorescobar (twitter) > > > > > > On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind > wrote: > >> On 7 June 2010 14:54, Igor Escobar wrote: >>> Hi Folks! >>> >>> The portal for which I work is suffering constant attacks that I >>> feel >> that >>> is PHP Injection. Somehow the hacker is getting to change the >>> cache files >>> that our system generates. Concatenating the HTML file with >>> another that >>> have an iframe to a malicious JAR file. Do you have any >>> suggestions to >>> prevent this action? The hacker has no access to our file system, >>> he is >>> imputing the code through some security hole. The problem is that >>> the >> portal >>> is very big and has lots and lots partners hosted on our estructure >>> structure. We are failing to identify the focus of this attacks. >>> >>> Any ideas? >>> >> >> Check all user input + upload: make sure that whatever comes from the >> user is validated. Then check all output: make sure that everythin >> output is escaped properly. Yes, it's an enormous task, but there's >> no >> way around it. >> >> Regards >> Peter >> >> -- >> >> WWW: http://plphp.dk / http://plind.dk >> LinkedIn: http://www.linkedin.com/in/plind >> BeWelcome/Couchsurfing: Fake51 >> Twitter: http://twitter.com/kafe15 >> >> htmlspecialchars() is really only good for user input that you are outputting to the browser. For inserting data into a database, use mysql_real_escape_string(). I find it's good to think carefully about what sort of data I expect and sanitise it accordingly. If I want a numerical value, I use intval($_GET['var']) or floatval(). For things like small text box elements, regex's work well depending on the data. For data from select lists of checkboxes, make sure the value given is within a list of pre-determined values you have. Basically, nothing from the user should be trusted at all, ever. As soon as you let go of that trust in the good honesty of people you'll do fine ;) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Security Issue
On Mon, 2010-06-07 at 10:38 -0700, Michael Shadle wrote: > It's not that bad. > > Use filter functions and sanity checks for input. > > Use htmlspecialchars() basically on output. > > That should take care of basically everything. > > On Jun 7, 2010, at 6:16 AM, Igor Escobar wrote: > > > This was my fear. > > > > Regards, > > Igor Escobar > > Systems Analyst & Interface Designer > > > > + http://blog.igorescobar.com > > + http://www.igorescobar.com > > + @igorescobar (twitter) > > > > > > > > > > > > On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind > > wrote: > > > >> On 7 June 2010 14:54, Igor Escobar wrote: > >>> Hi Folks! > >>> > >>> The portal for which I work is suffering constant attacks that I > >>> feel > >> that > >>> is PHP Injection. Somehow the hacker is getting to change the > >>> cache files > >>> that our system generates. Concatenating the HTML file with > >>> another that > >>> have an iframe to a malicious JAR file. Do you have any > >>> suggestions to > >>> prevent this action? The hacker has no access to our file system, > >>> he is > >>> imputing the code through some security hole. The problem is that > >>> the > >> portal > >>> is very big and has lots and lots partners hosted on our estructure > >>> structure. We are failing to identify the focus of this attacks. > >>> > >>> Any ideas? > >>> > >> > >> Check all user input + upload: make sure that whatever comes from the > >> user is validated. Then check all output: make sure that everythin > >> output is escaped properly. Yes, it's an enormous task, but there's > >> no > >> way around it. > >> > >> Regards > >> Peter > >> > >> -- > >> > >> WWW: http://plphp.dk / http://plind.dk > >> LinkedIn: http://www.linkedin.com/in/plind > >> BeWelcome/Couchsurfing: Fake51 > >> Twitter: http://twitter.com/kafe15 > >> > >> > htmlspecialchars() is really only good for user input that you are outputting to the browser. For inserting data into a database, use mysql_real_escape_string(). I find it's good to think carefully about what sort of data I expect and sanitise it accordingly. If I want a numerical value, I use intval($_GET['var']) or floatval(). For things like small text box elements, regex's work well depending on the data. For data from select lists of checkboxes, make sure the value given is within a list of pre-determined values you have. Basically, nothing from the user should be trusted at all, ever. As soon as you let go of that trust in the good honesty of people you'll do fine ;) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Security Issue
It's not a SQL Injection or XSS problem, Michael. It's a PHP Injection problem. I know how fix that but the web site is very very huge, have lots and lots of partners and i'm have a bug difficult do identify the focus of the problem. Got it? Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 2:38 PM, Michael Shadle wrote: > It's not that bad. > > Use filter functions and sanity checks for input. > > Use htmlspecialchars() basically on output. > > That should take care of basically everything. > > > On Jun 7, 2010, at 6:16 AM, Igor Escobar wrote: > > This was my fear. >> >> Regards, >> Igor Escobar >> Systems Analyst & Interface Designer >> >> + http://blog.igorescobar.com >> + http://www.igorescobar.com >> + @igorescobar (twitter) >> >> >> >> >> >> On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind >> wrote: >> >> On 7 June 2010 14:54, Igor Escobar wrote: >>> Hi Folks! The portal for which I work is suffering constant attacks that I feel >>> that >>> is PHP Injection. Somehow the hacker is getting to change the cache files that our system generates. Concatenating the HTML file with another that have an iframe to a malicious JAR file. Do you have any suggestions to prevent this action? The hacker has no access to our file system, he is imputing the code through some security hole. The problem is that the >>> portal >>> is very big and has lots and lots partners hosted on our estructure structure. We are failing to identify the focus of this attacks. Any ideas? >>> Check all user input + upload: make sure that whatever comes from the >>> user is validated. Then check all output: make sure that everythin >>> output is escaped properly. Yes, it's an enormous task, but there's no >>> way around it. >>> >>> Regards >>> Peter >>> >>> -- >>> >>> WWW: http://plphp.dk / http://plind.dk >>> LinkedIn: http://www.linkedin.com/in/plind >>> BeWelcome/Couchsurfing: Fake51 >>> Twitter: http://twitter.com/kafe15 >>> >>> >>> > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] Security Issue
It's not that bad. Use filter functions and sanity checks for input. Use htmlspecialchars() basically on output. That should take care of basically everything. On Jun 7, 2010, at 6:16 AM, Igor Escobar wrote: This was my fear. Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind wrote: On 7 June 2010 14:54, Igor Escobar wrote: Hi Folks! The portal for which I work is suffering constant attacks that I feel that is PHP Injection. Somehow the hacker is getting to change the cache files that our system generates. Concatenating the HTML file with another that have an iframe to a malicious JAR file. Do you have any suggestions to prevent this action? The hacker has no access to our file system, he is imputing the code through some security hole. The problem is that the portal is very big and has lots and lots partners hosted on our estructure structure. We are failing to identify the focus of this attacks. Any ideas? Check all user input + upload: make sure that whatever comes from the user is validated. Then check all output: make sure that everythin output is escaped properly. Yes, it's an enormous task, but there's no way around it. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Issue
There should be some clues in your httpd logs if it is coming in on the http request. Otherwise, you need to beef up the input sanitization all across the board. Some of that might be caught by verifying the users all have current versions of their applications in place. Bob McConnell -Original Message- From: Igor Escobar [mailto:titiolin...@gmail.com] Sent: Monday, June 07, 2010 9:21 AM To: Phpster Cc: Subject: Re: [PHP] Security Issue I do not believe he is doing so through forms but PHP Injection. We have already met one of the files that he used to make the concatenation of the cache files. Need to know if there is a tool, anything, that we can install on the server and identify the hacker more easily because the manual labor is not giving much result. Thanks for all support! Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 10:08 AM, Phpster wrote: > > On Jun 7, 2010, at 8:54 AM, Igor Escobar wrote: > > Hi Folks! >> >> The portal for which I work is suffering constant attacks that I feel that >> is PHP Injection. Somehow the hacker is getting to change the cache files >> that our system generates. Concatenating the HTML file with another that >> have an iframe to a malicious JAR file. Do you have any suggestions to >> prevent this action? The hacker has no access to our file system, he is >> imputing the code through some security hole. The problem is that the >> portal >> is very big and has lots and lots partners hosted on our estructure >> structure. We are failing to identify the focus of this attacks. >> >> Any ideas? >> >> >> Regards, >> Igor Escobar >> Systems Analyst & Interface Designer >> >> + http://blog.igorescobar.com >> + http://www.igorescobar.com >> + @igorescobar (twitter) >> > > Can you implement a simple form dump process that would catch the form name > an the data being entered and save that? That would allow you to at least > see what script has the hole as you trap it. > > Bastien > > Sent from my iPod > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Issue
I do not believe he is doing so through forms but PHP Injection. We have already met one of the files that he used to make the concatenation of the cache files. Need to know if there is a tool, anything, that we can install on the server and identify the hacker more easily because the manual labor is not giving much result. Thanks for all support! Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 10:08 AM, Phpster wrote: > > On Jun 7, 2010, at 8:54 AM, Igor Escobar wrote: > > Hi Folks! >> >> The portal for which I work is suffering constant attacks that I feel that >> is PHP Injection. Somehow the hacker is getting to change the cache files >> that our system generates. Concatenating the HTML file with another that >> have an iframe to a malicious JAR file. Do you have any suggestions to >> prevent this action? The hacker has no access to our file system, he is >> imputing the code through some security hole. The problem is that the >> portal >> is very big and has lots and lots partners hosted on our estructure >> structure. We are failing to identify the focus of this attacks. >> >> Any ideas? >> >> >> Regards, >> Igor Escobar >> Systems Analyst & Interface Designer >> >> + http://blog.igorescobar.com >> + http://www.igorescobar.com >> + @igorescobar (twitter) >> > > Can you implement a simple form dump process that would catch the form name > an the data being entered and save that? That would allow you to at least > see what script has the hole as you trap it. > > Bastien > > Sent from my iPod > >
Re: [PHP] Security Issue
This was my fear. Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind wrote: > On 7 June 2010 14:54, Igor Escobar wrote: > > Hi Folks! > > > > The portal for which I work is suffering constant attacks that I feel > that > > is PHP Injection. Somehow the hacker is getting to change the cache files > > that our system generates. Concatenating the HTML file with another that > > have an iframe to a malicious JAR file. Do you have any suggestions to > > prevent this action? The hacker has no access to our file system, he is > > imputing the code through some security hole. The problem is that the > portal > > is very big and has lots and lots partners hosted on our estructure > > structure. We are failing to identify the focus of this attacks. > > > > Any ideas? > > > > Check all user input + upload: make sure that whatever comes from the > user is validated. Then check all output: make sure that everythin > output is escaped properly. Yes, it's an enormous task, but there's no > way around it. > > Regards > Peter > > -- > > WWW: http://plphp.dk / http://plind.dk > LinkedIn: http://www.linkedin.com/in/plind > BeWelcome/Couchsurfing: Fake51 > Twitter: http://twitter.com/kafe15 > >
Re: [PHP] Security Issue
Hi Ashley! Thanks for helping us! OK, first thing, check all the file access logs, i.e. FTP logs, etc, just to make sure that it's not a case of a compromised password. There's a well-known issue with people who use FileZilla on Windows systems that allows passwords to be easily stolen. * * *We've done this before. FTP logs are clean. We limit access to FTP only authorized machines. * * * Next, see if you can isolate the IP address(s) that might be making these changes, and then go back over the HTTP access logs to determine what URLs they are visiting on the site. This should give you an idea about where the attack is coming in from. *I'll see if I can find a way to identify the IP of the person who changed the file last time. As he is injecting a PHP script within our server, the script itself is changing the file so it is assumed as the default user apache as who made the change.* Make sure that any pre-built systems (i.e. shopping carts, blog or forum software) is patched and up-to-date. A lot of attacks are targeted at sites en-mass because they are found to have the same flaw which, left unpatched, is like an open door to your server. *We always encourage our partners to keep their system current. They are usually blogs (wordpress) and plugins * It's also not a bad idea to change the passwords used to access the server, both for FTP and SSH. You might also need to scan the server with antivirus software (this is mainly for Windows servers really) to make sure that a rootkit hasn't been installed. *All access via username and password are clean, if we identify unauthorized access, we will certainly do that!* * * *Thank you for your help! Let's try to identify the IP address of the person who changed the file and then we try to trace your browsing history!* * *Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 10:03 AM, Ashley Sheridan wrote: > On Mon, 2010-06-07 at 09:54 -0300, Igor Escobar wrote: > > Hi Folks! > > The portal for which I work is suffering constant attacks that I feel that > is PHP Injection. Somehow the hacker is getting to change the cache files > that our system generates. Concatenating the HTML file with another that > have an iframe to a malicious JAR file. Do you have any suggestions to > prevent this action? The hacker has no access to our file system, he is > imputing the code through some security hole. The problem is that the portal > is very big and has lots and lots partners hosted on our estructure > structure. We are failing to identify the focus of this attacks. > > Any ideas? > > > Regards, > Igor Escobar > Systems Analyst & Interface Designer > > + http://blog.igorescobar.com > + http://www.igorescobar.com > + @igorescobar (twitter) > > > OK, first thing, check all the file access logs, i.e. FTP logs, etc, just > to make sure that it's not a case of a compromised password. There's a > well-known issue with people who use FileZilla on Windows systems that > allows passwords to be easily stolen. > > Next, see if you can isolate the IP address(s) that might be making these > changes, and then go back over the HTTP access logs to determine what URLs > they are visiting on the site. This should give you an idea about where the > attack is coming in from. > > Make sure that any pre-built systems (i.e. shopping carts, blog or forum > software) is patched and up-to-date. A lot of attacks are targeted at sites > en-mass because they are found to have the same flaw which, left unpatched, > is like an open door to your server. > > It's also not a bad idea to change the passwords used to access the server, > both for FTP and SSH. You might also need to scan the server with antivirus > software (this is mainly for Windows servers really) to make sure that a > rootkit hasn't been installed. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > >
Re: [PHP] Security Issue
On Jun 7, 2010, at 8:54 AM, Igor Escobar wrote: Hi Folks! The portal for which I work is suffering constant attacks that I feel that is PHP Injection. Somehow the hacker is getting to change the cache files that our system generates. Concatenating the HTML file with another that have an iframe to a malicious JAR file. Do you have any suggestions to prevent this action? The hacker has no access to our file system, he is imputing the code through some security hole. The problem is that the portal is very big and has lots and lots partners hosted on our estructure structure. We are failing to identify the focus of this attacks. Any ideas? Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) Can you implement a simple form dump process that would catch the form name an the data being entered and save that? That would allow you to at least see what script has the hole as you trap it. Bastien Sent from my iPod -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Issue
On 7 June 2010 14:54, Igor Escobar wrote: > Hi Folks! > > The portal for which I work is suffering constant attacks that I feel that > is PHP Injection. Somehow the hacker is getting to change the cache files > that our system generates. Concatenating the HTML file with another that > have an iframe to a malicious JAR file. Do you have any suggestions to > prevent this action? The hacker has no access to our file system, he is > imputing the code through some security hole. The problem is that the portal > is very big and has lots and lots partners hosted on our estructure > structure. We are failing to identify the focus of this attacks. > > Any ideas? > Check all user input + upload: make sure that whatever comes from the user is validated. Then check all output: make sure that everythin output is escaped properly. Yes, it's an enormous task, but there's no way around it. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Issue
On Mon, 2010-06-07 at 09:54 -0300, Igor Escobar wrote: > Hi Folks! > > The portal for which I work is suffering constant attacks that I feel that > is PHP Injection. Somehow the hacker is getting to change the cache files > that our system generates. Concatenating the HTML file with another that > have an iframe to a malicious JAR file. Do you have any suggestions to > prevent this action? The hacker has no access to our file system, he is > imputing the code through some security hole. The problem is that the portal > is very big and has lots and lots partners hosted on our estructure > structure. We are failing to identify the focus of this attacks. > > Any ideas? > > > Regards, > Igor Escobar > Systems Analyst & Interface Designer > > + http://blog.igorescobar.com > + http://www.igorescobar.com > + @igorescobar (twitter) OK, first thing, check all the file access logs, i.e. FTP logs, etc, just to make sure that it's not a case of a compromised password. There's a well-known issue with people who use FileZilla on Windows systems that allows passwords to be easily stolen. Next, see if you can isolate the IP address(s) that might be making these changes, and then go back over the HTTP access logs to determine what URLs they are visiting on the site. This should give you an idea about where the attack is coming in from. Make sure that any pre-built systems (i.e. shopping carts, blog or forum software) is patched and up-to-date. A lot of attacks are targeted at sites en-mass because they are found to have the same flaw which, left unpatched, is like an open door to your server. It's also not a bad idea to change the passwords used to access the server, both for FTP and SSH. You might also need to scan the server with antivirus software (this is mainly for Windows servers really) to make sure that a rootkit hasn't been installed. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Security/Development Question
At 4:54 PM -0400 4/28/10, David Stoltz wrote: My concern is passing SQL queries in this way is not best practice - am I wrong? Please let me know how you would react to this? David : First, you are not wrong. Second, that's exactly the type of security risk you want to protect yourself from. Third, never trust anything coming from client-side (i.e., POST, GET, or COOKIE). Now, they (the vendor) can throw all the layers of confusion/nonsense (it's SSL, APS.NET, or will happen later) on this as they want, but the point remains this is permitting client-side access to a database and that is NOT good. 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] Security/Development Question
Hi all, I am learning PHP and found this problem to be interesting. I personally would never do this myself. All the manuals I have read strictly prohibit this type of behavior. Wouldn't you just have them run the queries on their end and send you the results instead of the query itself? Curious to see what would be the best scenario for this when you have a third party involved. What would be the best way to have them format their data to send you? Best, Karl On Apr 28, 2010, at 4:23 PM, Programming Guides wrote: On Wed, Apr 28, 2010 at 4:02 PM, Andre Polykanine wrote: Hello David, I'm not a PHP god but I would never ever do such things.I can't even imagine what can be the reason of passing an SQL query through a form... -- With best regards from Ukraine, Andre Skype: Francophile; Wlm&MSN: arthaelon @ yandex.ru; Jabber: arthaelon @ jabber.org Yahoo! messenger: andre.polykanine; ICQ: 191749952 Twitter: m_elensule - Original message - From: David Stoltz To: php-general@lists.php.net Date: Wednesday, April 28, 2010, 11:54:56 PM Subject: [PHP] Security/Development Question Hi folks, This isn't really a PHP question per se, but could apply to any language... I have a public facing web server, which we have a software component that helps protect us from SQL Injection, and the like. We recently have added a very small web application that is vendor supported. They said it's not working, so I investigated. I found that our software protection was blocking their pages because they are actually passing entire SQL queries in their form POSTs. Now, the app is SSL protected, and they claim the queries are not executed - only inserted into the database to be used later. They also said it's protected by the ASP.NET framework authenticationnot sure about any of that. My concern is passing SQL queries in this way is not best practice - am I wrong? Please let me know how you would react to this? See below for the stuff they are passing in the POST (obvious things like table names have been changed): /wEWBQLciq6UBwLEhISFCwLa2223bD3wK3+56LBAKc37iSDEsHMFjpB6o1vHld19wT +Tt3sY 8E&CRITICAL_RESULT&on&Declare @critical varchar (40) set @critical = (select top 1 code from table where id = 'clr7' and thename = 'critical') sELECT OPR_SECD.REC USER_REC_NO, RESULT.*, (SELECT RESULT_DESC FROM table WHERE code = RESULT.RES_MSTR_CODE) [DESC], [ORDER].*, (SELECT VALUE FROM table WHERE this_CODE = 'Email' AND USER_REC = OPR_SECD.RECNUM) MBMD_EMAIL, OPR_SECD.OPR_INITIAL FROM RESULTING LEFT JOIN [ORDER] ON RESULTING.ORDER_REC = [ORDERBY].RECNUM LEFT JOIN OPR_SECD ON [ORDER].DR_CODE = OPR_SECD.XREF_CODE where (RESULT.FLAG_TEXT) = @critical AND RESULT.REC = @ID&Save -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I can't say that I agree with this design but it is certainly possible to prevent against crafted POST data. I think in your particular case they might be doing that judging by the presence of the hash at the beginning of the POST data (although that could be anything... I'm just guessing). A general way to prevent against crafted POST data is to have a session or even a page secret key. The key is hashed with the value which is then written to the (I suppose) hidden form field. When the POST data comes back it's hashed with the key and checked against the hash in the POST. So.. yes it's possible to prevent from crafting the POST data but the design is still crappy; I wouldn't do it. -- Viktor http://programming-guides.com Karl DeSaulniers Design Drumm http://designdrumm.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security/Development Question
On Wed, Apr 28, 2010 at 4:02 PM, Andre Polykanine wrote: > Hello David, > > I'm not a PHP god but I would never ever do such things.I can't even > imagine what can be the reason of passing an SQL query through a > form... > -- > With best regards from Ukraine, > Andre > Skype: Francophile; Wlm&MSN: arthaelon @ yandex.ru; Jabber: arthaelon @ > jabber.org > Yahoo! messenger: andre.polykanine; ICQ: 191749952 > Twitter: m_elensule > > - Original message - > From: David Stoltz > To: php-general@lists.php.net > Date: Wednesday, April 28, 2010, 11:54:56 PM > Subject: [PHP] Security/Development Question > > Hi folks, > > > > This isn't really a PHP question per se, but could apply to any > language... > > > > I have a public facing web server, which we have a software component > that helps protect us from SQL Injection, and the like. > > > > We recently have added a very small web application that is vendor > supported. They said it's not working, so I investigated. I found that > our software protection was blocking their pages because they are > actually passing entire SQL queries in their form POSTs. Now, the app is > SSL protected, and they claim the queries are not executed - only > inserted into the database to be used later. They also said it's > protected by the ASP.NET framework authenticationnot sure about any > of that. > > > > My concern is passing SQL queries in this way is not best practice - am > I wrong? Please let me know how you would react to this? > > > > See below for the stuff they are passing in the POST (obvious things > like table names have been changed): > > > > /wEWBQLciq6UBwLEhISFCwLa2223bD3wK3+56LBAKc37iSDEsHMFjpB6o1vHld19wT+Tt3sY > 8E&CRITICAL_RESULT&on&Declare @critical varchar (40) > > set @critical = (select top 1 code from table where id = 'clr7' and > thename = 'critical') > > > > sELECT > > OPR_SECD.REC USER_REC_NO, > > RESULT.*, > > (SELECT RESULT_DESC FROM table WHERE code = RESULT.RES_MSTR_CODE) > [DESC], > > [ORDER].*, > > (SELECT VALUE FROM table WHERE this_CODE = 'Email' AND USER_REC = > OPR_SECD.RECNUM) MBMD_EMAIL, > > OPR_SECD.OPR_INITIAL > > FROM RESULTING LEFT JOIN [ORDER] ON RESULTING.ORDER_REC = > [ORDERBY].RECNUM > > LEFT JOIN OPR_SECD ON [ORDER].DR_CODE = OPR_SECD.XREF_CODE > > where (RESULT.FLAG_TEXT) = @critical AND RESULT.REC = @ID&Save > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > I can't say that I agree with this design but it is certainly possible to prevent against crafted POST data. I think in your particular case they might be doing that judging by the presence of the hash at the beginning of the POST data (although that could be anything... I'm just guessing). A general way to prevent against crafted POST data is to have a session or even a page secret key. The key is hashed with the value which is then written to the (I suppose) hidden form field. When the POST data comes back it's hashed with the key and checked against the hash in the POST. So.. yes it's possible to prevent from crafting the POST data but the design is still crappy; I wouldn't do it. -- Viktor http://programming-guides.com
Re: [PHP] Security/Development Question
David Stoltz wrote: Hi folks, This isn't really a PHP question per se, but could apply to any language... I have a public facing web server, which we have a software component that helps protect us from SQL Injection, and the like. We recently have added a very small web application that is vendor supported. They said it's not working, so I investigated. I found that our software protection was blocking their pages because they are actually passing entire SQL queries in their form POSTs. Run... scream and run... to the server and get it off :) Ok, maybe it's not that bad... read on for more! Now, the app is SSL protected, and they claim the queries are not executed - only inserted into the database to be used later. TO BE USED LATER??? AS IN EXECUTED? It doesn't matter if you stave off an injection attack till a week from today, it still will screw up your database. They also said it's protected by the ASP.NET framework authenticationnot sure about any of that. Me neither... but I'd still be worried. Maybe the query was created on the server and a checksum or hash was createwd to ensure no tampering with the query. But still, I would worry that you are revealing information about your database to the public. No information leakage is the best kind of leakage. My concern is passing SQL queries in this way is not best practice - am I wrong? Please let me know how you would react to this? You are right. This is shoddy practice. See below for the stuff they are passing in the POST (obvious things like table names have been changed): /wEWBQLciq6UBwLEhISFCwLa2223bD3wK3+56LBAKc37iSDEsHMFjpB6o1vHld19wT+Tt3sY 8E The above portion is probably the checksum / hash to detect tampering... AKA if I understand correctly... the "ASP.NET framework authentication". &CRITICAL_RESULT&on&Declare @critical varchar (40) set @critical = (select top 1 code from table where id = 'clr7' and thename = 'critical') sELECT OPR_SECD.REC USER_REC_NO, RESULT.*, (SELECT RESULT_DESC FROM table WHERE code = RESULT.RES_MSTR_CODE) [DESC], [ORDER].*, (SELECT VALUE FROM table WHERE this_CODE = 'Email' AND USER_REC = OPR_SECD.RECNUM) MBMD_EMAIL, OPR_SECD.OPR_INITIAL FROM RESULTING LEFT JOIN [ORDER] ON RESULTING.ORDER_REC = [ORDERBY].RECNUM LEFT JOIN OPR_SECD ON [ORDER].DR_CODE = OPR_SECD.XREF_CODE where (RESULT.FLAG_TEXT) = @critical AND RESULT.REC = @ID&Save Nice of them to share the database structure with the public. The query may be secure from tampering, but it is terrible practice to reveal internal design to the public. Although, admittedly in this day and age of open source applications like drupal/joomla/mediawiki/other the public knows your database structure unless you choose an offbeat table prefix :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security/Development Question
On Wed, Apr 28, 2010 at 04:54:56PM -0400, David Stoltz wrote: > Hi folks, > > > > This isn't really a PHP question per se, but could apply to any > language... > > > > I have a public facing web server, which we have a software component > that helps protect us from SQL Injection, and the like. > > > > We recently have added a very small web application that is vendor > supported. They said it's not working, so I investigated. I found that > our software protection was blocking their pages because they are > actually passing entire SQL queries in their form POSTs. Now, the app is > SSL protected, and they claim the queries are not executed - only > inserted into the database to be used later. They also said it's > protected by the ASP.NET framework authenticationnot sure about any > of that. > > > > My concern is passing SQL queries in this way is not best practice - am > I wrong? Please let me know how you would react to this? > > > > See below for the stuff they are passing in the POST (obvious things > like table names have been changed): > > > > /wEWBQLciq6UBwLEhISFCwLa2223bD3wK3+56LBAKc37iSDEsHMFjpB6o1vHld19wT+Tt3sY > 8E&CRITICAL_RESULT&on&Declare @critical varchar (40) > > set @critical = (select top 1 code from table where id = 'clr7' and > thename = 'critical') > > > > sELECT > > OPR_SECD.REC USER_REC_NO, > > RESULT.*, > > (SELECT RESULT_DESC FROM table WHERE code = RESULT.RES_MSTR_CODE) > [DESC], > > [ORDER].*, > > (SELECT VALUE FROM table WHERE this_CODE = 'Email' AND USER_REC = > OPR_SECD.RECNUM) MBMD_EMAIL, > > OPR_SECD.OPR_INITIAL > > FROM RESULTING LEFT JOIN [ORDER] ON RESULTING.ORDER_REC = > [ORDERBY].RECNUM > > LEFT JOIN OPR_SECD ON [ORDER].DR_CODE = OPR_SECD.XREF_CODE > > where (RESULT.FLAG_TEXT) = @critical AND RESULT.REC = @ID&Save > Holy crap! There's a very good reason why your security application is blocking their software. You have no control over these SQL strings, and injection could occur if only by accident if you're not in control of them. The only thing I can imagine worse than passing a SQL query around in a POST variable is passing it around in a GET variable. Sometimes I wonder where programmers like this come from. I'm not that good with security, but even I wouldn't do this. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security/Development Question
Hello David, I'm not a PHP god but I would never ever do such things.I can't even imagine what can be the reason of passing an SQL query through a form... -- With best regards from Ukraine, Andre Skype: Francophile; Wlm&MSN: arthaelon @ yandex.ru; Jabber: arthaelon @ jabber.org Yahoo! messenger: andre.polykanine; ICQ: 191749952 Twitter: m_elensule - Original message - From: David Stoltz To: php-general@lists.php.net Date: Wednesday, April 28, 2010, 11:54:56 PM Subject: [PHP] Security/Development Question Hi folks, This isn't really a PHP question per se, but could apply to any language... I have a public facing web server, which we have a software component that helps protect us from SQL Injection, and the like. We recently have added a very small web application that is vendor supported. They said it's not working, so I investigated. I found that our software protection was blocking their pages because they are actually passing entire SQL queries in their form POSTs. Now, the app is SSL protected, and they claim the queries are not executed - only inserted into the database to be used later. They also said it's protected by the ASP.NET framework authenticationnot sure about any of that. My concern is passing SQL queries in this way is not best practice - am I wrong? Please let me know how you would react to this? See below for the stuff they are passing in the POST (obvious things like table names have been changed): /wEWBQLciq6UBwLEhISFCwLa2223bD3wK3+56LBAKc37iSDEsHMFjpB6o1vHld19wT+Tt3sY 8E&CRITICAL_RESULT&on&Declare @critical varchar (40) set @critical = (select top 1 code from table where id = 'clr7' and thename = 'critical') sELECT OPR_SECD.REC USER_REC_NO, RESULT.*, (SELECT RESULT_DESC FROM table WHERE code = RESULT.RES_MSTR_CODE) [DESC], [ORDER].*, (SELECT VALUE FROM table WHERE this_CODE = 'Email' AND USER_REC = OPR_SECD.RECNUM) MBMD_EMAIL, OPR_SECD.OPR_INITIAL FROM RESULTING LEFT JOIN [ORDER] ON RESULTING.ORDER_REC = [ORDERBY].RECNUM LEFT JOIN OPR_SECD ON [ORDER].DR_CODE = OPR_SECD.XREF_CODE where (RESULT.FLAG_TEXT) = @critical AND RESULT.REC = @ID&Save -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security/deployment issue
> Humm.. thanks for the replies. But i have another problem about rsync > again. > > > > When i deploy a project using the rsync the permissions of all home > directory is changed. i tried to use the parameter -p -o -g (preserve > permissions, owner and group): > > > I dont know but the rsync doesnt preserve the permissions and group/owner. > > > Then always after a deploy i need to execute the cmd "chmod 755 user:group > /home/project" . Have someone this problem? > > > Thanks > > > Augusto Morais > That would sugest that you are running PHP as the same user as Apache, instead running it as the user which owns the files (the same user you are using with rsync) would solve this problem. This can be done by running php as a fastcgi application with suexec or using mpm-itk. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security/deployment issue
Rsync preserves the UID and GID, not the visible username or visible group name. This means that if the UIDs and GIDs do not match your expected users and groups on the destination server they will match whatever is setup there according to the /etc/passwd or /etc/group files. If there's no match for the UID and GID then it will just display the UID or GID number. Adam. On Fri, Oct 16, 2009 at 1:13 PM, Augusto Flavio wrote: > Humm.. thanks for the replies. But i have another problem about rsync again. > > > > When i deploy a project using the rsync the permissions of all home > directory is changed. i tried to use the parameter -p -o -g (preserve > permissions, owner and group): > > > I dont know but the rsync doesnt preserve the permissions and group/owner. > > > Then always after a deploy i need to execute the cmd "chmod 755 user:group > /home/project" . Have someone this problem? > > > Thanks > > > Augusto Morais > -- Adam Randall http://www.xaren.net AIM: blitz574 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security/deployment issue
Humm.. thanks for the replies. But i have another problem about rsync again. When i deploy a project using the rsync the permissions of all home directory is changed. i tried to use the parameter -p -o -g (preserve permissions, owner and group): I dont know but the rsync doesnt preserve the permissions and group/owner. Then always after a deploy i need to execute the cmd "chmod 755 user:group /home/project" . Have someone this problem? Thanks Augusto Morais
Re: [PHP] security/deployment issue
>> Rsync should work fine, but personally I like to see exactly which >> changes are being deployed especially when deploying to production. >> While I realise this recommendation is not Open Source software, I >> have found it to be an excellent piece of software for this task. I >> use Beyond Compare which has the ability to connect over SFTP or SCP >> as well as regular FTP. It allows you to 'diff' the files as you go >> and view exact changes and you can transfer only the changes you want >> or whole files if you choose to. I would not be surprised if an Open >> Source equivalent exists. > > What about SVN? you can do a svn export. Or you can have a working > copy for production too. > Just dont forget to deny access to .svn in your webserver. > Here are directives for Apache: > > > Order allow,deny > Deny from all > > I do exactly this, its handy to be able to check out the latest version of a website, make some changes and commit it again, while having acsess to the complete revision history, from absolutely anywhere. SVN works over HTTPS, so can go straight through most firewalls without anyone noticing and it also does data transmissions (like RSync) which can be a LOT faster than re uploading the whole file with SFTP etc. There are some security issues in a shared hosting environment though, if you use a commit hook to update the web root on commit using a file:/// URL anyone on the server could check out / commit files from the repository. As of right now the only work around that I can think of for this would be to run two apches at the same time, one for SVN, and one for the main HTTP server which is chrooted to block access to the SVN repos and have the non chrooted server revere proxy connections to the chrooted one. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security/deployment issue
> Rsync should work fine, but personally I like to see exactly which > changes are being deployed especially when deploying to production. > While I realise this recommendation is not Open Source software, I > have found it to be an excellent piece of software for this task. I > use Beyond Compare which has the ability to connect over SFTP or SCP > as well as regular FTP. It allows you to 'diff' the files as you go > and view exact changes and you can transfer only the changes you want > or whole files if you choose to. I would not be surprised if an Open > Source equivalent exists. What about SVN? you can do a svn export. Or you can have a working copy for production too. Just dont forget to deny access to .svn in your webserver. Here are directives for Apache: Order allow,deny Deny from all -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security/deployment issue
On Mon, Oct 12, 2009 at 4:06 PM, Augusto Flavio wrote: > i have a doubt about my security and deployment methods. Today i manage > several projects and these projects are versioned with subversion. My > environment is something like this: > > 1. The developer make some update in the source code of a project. (from > your IDE, generally netbeans) > 2. The developer commit the modifications to the subversion server after > test it(sure). > 3. The project manager sync the files from the dev server to the prod > server(using rsync). Sounds mostly fine. I assume you have other testing going on before deployment to production, though. > Well, my questions are 2. All about the rsync: > > 1. For each project we have a ssh user that is used to sync the files(source > code) to the prod server. The problem that i see here is that for each > project i need to have a ssh account to sync these files. This is not so > cool because i need to have severals actived ssh accounts in my prod server. > I'm thinking about the root account to do this work. Is this a good > practice? The root account is not a very good idea for this. You could create a 'service' account that is used exclusively for transferring the files to the server. To allow this user access to the various source directories you can use something like ACL's or perhaps even regular UNIX file permissions may work if your needs aren't very complex. > 2. Does have some another way, more better than the rsync for this > deployment issue? Rsync should work fine, but personally I like to see exactly which changes are being deployed especially when deploying to production. While I realise this recommendation is not Open Source software, I have found it to be an excellent piece of software for this task. I use Beyond Compare which has the ability to connect over SFTP or SCP as well as regular FTP. It allows you to 'diff' the files as you go and view exact changes and you can transfer only the changes you want or whole files if you choose to. I would not be surprised if an Open Source equivalent exists. Cheers, James -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] security question of ZCE exam
On Tue, Aug 25, 2009 at 00:07, Augusto Flavio wrote: > > Answers: (choose 2) > Error messages will contain sensitive session information > Error messages can contain cross site scripting attacks > Security risks involved in logging are handled by PHP > X Error messages give the perception of insecurity to the user > X Error messages can contain data useful to a potential attacker > > > My answers is marked with a X. > > > some clue about this? Yes, and my answers are marked with an X. XBuy a study guide. XDo your own homework. -- daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Check out our great hosting and dedicated server deals at http://twitter.com/pilotpig -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
On Tue, Jun 2, 2009 at 7:39 PM, Shawn McKenzie wrote: > Grant Peel wrote: >> Hi all, >> >> I am currently setting up the next generation web server for our company and >> am in need of general consulting/advice on php set up security issues. >> >> Any one with knowledge and expierience please feel free to reply :-). >> >> -Grant > > Do not under any circumstances put the web server on the Internet. > > -- > Thanks! > -Shawn > http://www.spidean.com > Furthermore, disconnect all storage media to make sure no one is able to access files that they should not access, remove any network interface cards and smash them to make sure malicious users cannot even connect to the machine, and fill any I/O ports with superglue to ensure that no one can plug any unauthorized devices. Oh, and be sure to remove the power supply to prevent local terminal access. ;-) Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Grant Peel wrote: ??? I think you can safely assume that was a joke. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
??? - Original Message - From: "Shawn McKenzie" To: Sent: Tuesday, June 02, 2009 7:39 PM Subject: [PHP] Re: PHP Security Grant Peel wrote: Hi all, I am currently setting up the next generation web server for our company and am in need of general consulting/advice on php set up security issues. Any one with knowledge and expierience please feel free to reply :-). -Grant Do not under any circumstances put the web server on the Internet. -- Thanks! -Shawn http://www.spidean.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
[PHP] Re: PHP Security
Grant Peel wrote: > Hi all, > > I am currently setting up the next generation web server for our company and > am in need of general consulting/advice on php set up security issues. > > Any one with knowledge and expierience please feel free to reply :-). > > -Grant Do not under any circumstances put the web server on the Internet. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
not related to SQl but u may want to look at http://php-ids.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
On Fri, May 22, 2009 at 6:35 AM, Andrew Williams wrote: > WHY IS php-general@lists.php.net PUBLISHING USER EMAIL ON THE INTERNET: > > http://www.google.co.uk/search?q=sumitphp5%40gmail.com&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_enGB303GB303&aq=t > > On Fri, May 22, 2009 at 11:28 AM, Sumit Sharma wrote: > >> Thanks to [0] => Ashley, [1] =>Bruce, [2] => Michael, [3] => Shawn, [4] => >> Eddie and php-general list for all your support from bottom of my heart. >> >> >> Now it seems as if I will be able to design my project more secured than >> before. If you get >> any other idea please suggest me. >> >> >> Thanks, >> Sumit. >> >> >> >> >> >> >> >> -- Forwarded message -- >> From: Michael A. Peters >> Date: Fri, May 22, 2009 at 4:50 AM >> Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE >> To: Eddie Drapkin >> Cc: php-general@lists.php.net >> >> >> Eddie Drapkin wrote: >> >> > Suhosin is completely not-related to SQL, though, I don't know why you'd >> > bring it up... >> > >> >> I brought it up because suhosin catches many exploits that otherwise get >> through, including exploits that allow inclusion of remote files that can >> then be used to run arbitrary commands on the server, send include files >> (such as the db authentication script) as plain text, all kinds of nasty >> can >> result. >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > > -- > Best Wishes > A Williams > Because the lists are archived by several sites, and those archives are indexed by search engines. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
WHY IS php-general@lists.php.net PUBLISHING USER EMAIL ON THE INTERNET: http://www.google.co.uk/search?q=sumitphp5%40gmail.com&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_enGB303GB303&aq=t On Fri, May 22, 2009 at 11:28 AM, Sumit Sharma wrote: > Thanks to [0] => Ashley, [1] =>Bruce, [2] => Michael, [3] => Shawn, [4] => > Eddie and php-general list for all your support from bottom of my heart. > > > Now it seems as if I will be able to design my project more secured than > before. If you get > any other idea please suggest me. > > > Thanks, >Sumit. > > > > > > > > -- Forwarded message ---------- > From: Michael A. Peters > Date: Fri, May 22, 2009 at 4:50 AM > Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE > To: Eddie Drapkin > Cc: php-general@lists.php.net > > > Eddie Drapkin wrote: > > > Suhosin is completely not-related to SQL, though, I don't know why you'd > > bring it up... > > > > I brought it up because suhosin catches many exploits that otherwise get > through, including exploits that allow inclusion of remote files that can > then be used to run arbitrary commands on the server, send include files > (such as the db authentication script) as plain text, all kinds of nasty > can > result. > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- Best Wishes A Williams
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
Eddie Drapkin wrote: Suhosin is completely not-related to SQL, though, I don't know why you'd bring it up... I brought it up because suhosin catches many exploits that otherwise get through, including exploits that allow inclusion of remote files that can then be used to run arbitrary commands on the server, send include files (such as the db authentication script) as plain text, all kinds of nasty can result. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
Eddie Drapkin wrote:
> Suhosin is completely not-related to SQL, though, I don't know why you'd
> bring it up...
Well, because the post that I was replying to brought it up and I happen
to agree that it's a good idea even though it has nothing to do with SQL :-)
>>> Michael A. Peters wrote:
Use prepared statements.
If you are just starting out, I would recommend using a database
abstraction layer, such as MDB2 from pear.
Doing it now is a LOT easier than porting an existing web application to
use a database abstraction layer.
With prepared statement, sql injection is not an issue.
Example of prepared statement with MDB2:
$types = Array('integer','text','integer');
$q = 'SELECT somefield,someotherfield FROM sometable WHERE afield > ?
AND bfield=? AND cfield < ? ORDER BY somefield';
$sql = $mdb2->prepare($q,$types,MDB2_PREPARE_RESULT);
$args = Array($var1,$var2,$var3);
$rs = $sql->execute($args);
Prepared statements pretty much neuter any and all sql injection
attempts, assuming the database supports prepared statements (otherwise
the abstraction layer may emulate them which could possibly be prone to
vulnerabilities).
While you do not need to use an abstraction layer to use prepared
statements, the advantage of an abstraction layer is that your code will
be much easier to port to a different database - advantageous to your
client if they ever want to change databases, advantageous to you if you
ever want to resuse you code for another client (assuming your contract
does not give exclusive ownership of your code to your existing client).
The user the web server connects with should be as restricted as
possible. It should only have permission to connect to the database from
the host where the web server is running (localhost if running on same
machine as the sql server) and should not be granted any permissions it
does not absolutely need.
The file containing the database authentication credentials should end
in .php and not .inc, and if at all possible, should be outside the web
root (you can modify the include path to add a directory outside the web
root that has includes - or include the file full path).
Make sure error reporting is turned off on the production web server
(you can still read errors in the web server log).
*If at all possible, run php compiled with the suhosin core patch and
also run the suhosin loadable module.*
-=-
You shouldn't need addslashes with prepared statements.
You should run user input through an existed tested input filter, such
as http://htmlpurifier.org/ rather than trying to re-invent the wheel
and create your own. Script kiddies have scripts that test webapps for
input vulnerabilities (both xss and sql injection), and some of them are
rather tricky and browser specific.
A community driven project like HTMLPurifier is more likely to catch
malicious input than something you cobble together.
>>> PDO is another good option. You shouldn't have to worry about escaping
>>> or SQL injections, though suhosin is a great idea.
>>>
>>> http://php.net/manual/book.pdo.php
>>>
>>> --
>>> Thanks!
>>> -Shawn
>>> http://www.spidean.com
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>
--
Thanks!
-Shawn
http://www.spidean.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
Suhosin is completely not-related to SQL, though, I don't know why you'd
bring it up...
>
>
>
> On Thu, May 21, 2009 at 3:42 PM, Shawn McKenzie wrote:
>
>> Michael A. Peters wrote:
>> > Sumit Sharma wrote:
>> >> Hi,
>> >>
>> >> I am designing a php website for my client which interact with
>> database.
>> >> This is my first project for any client (I hope he is not reading this
>> >> mail
>> >> ;-) ). I am a bit more concerned with database security. Can somebody
>> >> shed
>> >> some light on the security measurements, precautions, and functions
>> >> related
>> >> to database security in general to make sure that the data is safely
>> >> stored
>> >> updated and retried from database. I have already used htmlentities(),
>> >> strip_tags(), addhashes(), and some regular expressions to check
>> >> security.
>> >> Looking for help beyond this.
>> >>
>> >>
>> >> Thanks in advance...
>> >> Sumit
>> >>
>> >
>> > Use prepared statements.
>> > If you are just starting out, I would recommend using a database
>> > abstraction layer, such as MDB2 from pear.
>> >
>> > Doing it now is a LOT easier than porting an existing web application to
>> > use a database abstraction layer.
>> >
>> > With prepared statement, sql injection is not an issue.
>> >
>> > Example of prepared statement with MDB2:
>> >
>> > $types = Array('integer','text','integer');
>> > $q = 'SELECT somefield,someotherfield FROM sometable WHERE afield > ?
>> > AND bfield=? AND cfield < ? ORDER BY somefield';
>> > $sql = $mdb2->prepare($q,$types,MDB2_PREPARE_RESULT);
>> >
>> > $args = Array($var1,$var2,$var3);
>> > $rs = $sql->execute($args);
>> >
>> > Prepared statements pretty much neuter any and all sql injection
>> > attempts, assuming the database supports prepared statements (otherwise
>> > the abstraction layer may emulate them which could possibly be prone to
>> > vulnerabilities).
>> >
>> > While you do not need to use an abstraction layer to use prepared
>> > statements, the advantage of an abstraction layer is that your code will
>> > be much easier to port to a different database - advantageous to your
>> > client if they ever want to change databases, advantageous to you if you
>> > ever want to resuse you code for another client (assuming your contract
>> > does not give exclusive ownership of your code to your existing client).
>> >
>> > The user the web server connects with should be as restricted as
>> > possible. It should only have permission to connect to the database from
>> > the host where the web server is running (localhost if running on same
>> > machine as the sql server) and should not be granted any permissions it
>> > does not absolutely need.
>> >
>> > The file containing the database authentication credentials should end
>> > in .php and not .inc, and if at all possible, should be outside the web
>> > root (you can modify the include path to add a directory outside the web
>> > root that has includes - or include the file full path).
>> >
>> > Make sure error reporting is turned off on the production web server
>> > (you can still read errors in the web server log).
>> >
>> > If at all possible, run php compiled with the suhosin core patch and
>> > also run the suhosin loadable module.
>> >
>> > -=-
>> > You shouldn't need addslashes with prepared statements.
>> > You should run user input through an existed tested input filter, such
>> > as http://htmlpurifier.org/ rather than trying to re-invent the wheel
>> > and create your own. Script kiddies have scripts that test webapps for
>> > input vulnerabilities (both xss and sql injection), and some of them are
>> > rather tricky and browser specific.
>> >
>> > A community driven project like HTMLPurifier is more likely to catch
>> > malicious input than something you cobble together.
>>
>> PDO is another good option. You shouldn't have to worry about escaping
>> or SQL injections, though suhosin is a great idea.
>>
>> http://php.net/manual/book.pdo.php
>>
>> --
>> Thanks!
>> -Shawn
>> http://www.spidean.com
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
Michael A. Peters wrote:
> Sumit Sharma wrote:
>> Hi,
>>
>> I am designing a php website for my client which interact with database.
>> This is my first project for any client (I hope he is not reading this
>> mail
>> ;-) ). I am a bit more concerned with database security. Can somebody
>> shed
>> some light on the security measurements, precautions, and functions
>> related
>> to database security in general to make sure that the data is safely
>> stored
>> updated and retried from database. I have already used htmlentities(),
>> strip_tags(), addhashes(), and some regular expressions to check
>> security.
>> Looking for help beyond this.
>>
>>
>> Thanks in advance...
>> Sumit
>>
>
> Use prepared statements.
> If you are just starting out, I would recommend using a database
> abstraction layer, such as MDB2 from pear.
>
> Doing it now is a LOT easier than porting an existing web application to
> use a database abstraction layer.
>
> With prepared statement, sql injection is not an issue.
>
> Example of prepared statement with MDB2:
>
> $types = Array('integer','text','integer');
> $q = 'SELECT somefield,someotherfield FROM sometable WHERE afield > ?
> AND bfield=? AND cfield < ? ORDER BY somefield';
> $sql = $mdb2->prepare($q,$types,MDB2_PREPARE_RESULT);
>
> $args = Array($var1,$var2,$var3);
> $rs = $sql->execute($args);
>
> Prepared statements pretty much neuter any and all sql injection
> attempts, assuming the database supports prepared statements (otherwise
> the abstraction layer may emulate them which could possibly be prone to
> vulnerabilities).
>
> While you do not need to use an abstraction layer to use prepared
> statements, the advantage of an abstraction layer is that your code will
> be much easier to port to a different database - advantageous to your
> client if they ever want to change databases, advantageous to you if you
> ever want to resuse you code for another client (assuming your contract
> does not give exclusive ownership of your code to your existing client).
>
> The user the web server connects with should be as restricted as
> possible. It should only have permission to connect to the database from
> the host where the web server is running (localhost if running on same
> machine as the sql server) and should not be granted any permissions it
> does not absolutely need.
>
> The file containing the database authentication credentials should end
> in .php and not .inc, and if at all possible, should be outside the web
> root (you can modify the include path to add a directory outside the web
> root that has includes - or include the file full path).
>
> Make sure error reporting is turned off on the production web server
> (you can still read errors in the web server log).
>
> If at all possible, run php compiled with the suhosin core patch and
> also run the suhosin loadable module.
>
> -=-
> You shouldn't need addslashes with prepared statements.
> You should run user input through an existed tested input filter, such
> as http://htmlpurifier.org/ rather than trying to re-invent the wheel
> and create your own. Script kiddies have scripts that test webapps for
> input vulnerabilities (both xss and sql injection), and some of them are
> rather tricky and browser specific.
>
> A community driven project like HTMLPurifier is more likely to catch
> malicious input than something you cobble together.
PDO is another good option. You shouldn't have to worry about escaping
or SQL injections, though suhosin is a great idea.
http://php.net/manual/book.pdo.php
--
Thanks!
-Shawn
http://www.spidean.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
Sumit Sharma wrote:
Hi,
I am designing a php website for my client which interact with database.
This is my first project for any client (I hope he is not reading this mail
;-) ). I am a bit more concerned with database security. Can somebody shed
some light on the security measurements, precautions, and functions related
to database security in general to make sure that the data is safely stored
updated and retried from database. I have already used htmlentities(),
strip_tags(), addhashes(), and some regular expressions to check security.
Looking for help beyond this.
Thanks in advance...
Sumit
Use prepared statements.
If you are just starting out, I would recommend using a database
abstraction layer, such as MDB2 from pear.
Doing it now is a LOT easier than porting an existing web application to
use a database abstraction layer.
With prepared statement, sql injection is not an issue.
Example of prepared statement with MDB2:
$types = Array('integer','text','integer');
$q = 'SELECT somefield,someotherfield FROM sometable WHERE afield > ?
AND bfield=? AND cfield < ? ORDER BY somefield';
$sql = $mdb2->prepare($q,$types,MDB2_PREPARE_RESULT);
$args = Array($var1,$var2,$var3);
$rs = $sql->execute($args);
Prepared statements pretty much neuter any and all sql injection
attempts, assuming the database supports prepared statements (otherwise
the abstraction layer may emulate them which could possibly be prone to
vulnerabilities).
While you do not need to use an abstraction layer to use prepared
statements, the advantage of an abstraction layer is that your code will
be much easier to port to a different database - advantageous to your
client if they ever want to change databases, advantageous to you if you
ever want to resuse you code for another client (assuming your contract
does not give exclusive ownership of your code to your existing client).
The user the web server connects with should be as restricted as
possible. It should only have permission to connect to the database from
the host where the web server is running (localhost if running on same
machine as the sql server) and should not be granted any permissions it
does not absolutely need.
The file containing the database authentication credentials should end
in .php and not .inc, and if at all possible, should be outside the web
root (you can modify the include path to add a directory outside the web
root that has includes - or include the file full path).
Make sure error reporting is turned off on the production web server
(you can still read errors in the web server log).
If at all possible, run php compiled with the suhosin core patch and
also run the suhosin loadable module.
-=-
You shouldn't need addslashes with prepared statements.
You should run user input through an existed tested input filter, such
as http://htmlpurifier.org/ rather than trying to re-invent the wheel
and create your own. Script kiddies have scripts that test webapps for
input vulnerabilities (both xss and sql injection), and some of them are
rather tricky and browser specific.
A community driven project like HTMLPurifier is more likely to catch
malicious input than something you cobble together.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
On Thu, 2009-05-21 at 18:22 +0530, Sumit Sharma wrote: > Hi, > > I am designing a php website for my client which interact with database. > This is my first project for any client (I hope he is not reading this mail > ;-) ). I am a bit more concerned with database security. Can somebody shed > some light on the security measurements, precautions, and functions related > to database security in general to make sure that the data is safely stored > updated and retried from database. I have already used htmlentities(), > strip_tags(), addhashes(), and some regular expressions to check security. > Looking for help beyond this. > > > Thanks in advance... > Sumit I'd advise using something like mysql_real_escape_string() (assuming you are using a MySQL database that is) on each variable of data before you insert it into the database. You could go further and validate specific data, so check that a field which you expect a number only contains a number, etc. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Support
From: Grant Peel > From: "Michael A. Peters" >> Grant Peel wrote: >>> Good Morning / Afternoon, >>> >>> We run several of our own servers: >>> >>> - Dell Power Edge 1U, Pentium, >>> - FreeBSD (6.x soon to be 7.x) >>> - along with all the standard Web Application installation (PHP Apache >>> Exim, Pop3, Proftp, MySQL etc etc). >>> >>> What I am asking here, is if any one in this community has the knowledge >>> to act as a security consultant in an occasional, as required basis. >>> Anyone interested should have expience with Apache, PHP, Perl on the >>> FreeBSD platform. >> >> No experience with FreeBSD and probably not enough with Perl - but whoever >> you hire, make sure they suggest your php build is hardened by suhosin - >> both the core php patch and the loadable module. >> > > Hi Again all, > > I am not sure what to make of all the chatter on this post > > To date, I have not recieved any sincere replies, which is a bit suprising. > I am thinking that this job would be easy money for someone who already > knows the ins and outs of php/Apache from a secuirty standpoint. > > I already have sohosin patch applied (it is applied as part of the default > FreeBSD - php port). > > Anyways, the offer is still out there if anyone is interested. Hi Grant, First off, I believe you are asking on the wrong list. Server security is an advanced topic, well outside the experience of most novice PHP developers. You would be better off asking on some of the advanced Apache or Perl Monks mailing lists. Second, from your brief description, I can easily picture a full time job with lots of overtime hours, not something most consultants will be interested in. Security is not easy to do correctly, particularly if you are not responsible and accountable for the outcome or don't have full authority and management support. We currently have a team of five people who are jointly responsible for the security of our servers and networks. Each of them spends more than 20% of their time on that portion of their job. And finally, there are companies that do what you asked for. Gibson Research(*) is the first one that comes to mind . They also provide monitoring services to keep an eye out for intrusions on your servers once they have been hardened. Foundstone(**) is another . Good luck, Bob McConnell Senior Software Engineer The CBORD Group, Inc. 61 Brown Road Ithaca NY, 14850 Phone 607 257-2410 FAX 607 257-1902 Email r...@cbord.com Web www.cbord.com (*) No relationship exists nor is implied, we're not even a customer. I just like his style. Plus his Shields Up test gave my home firewall a perfect score. (**) We have occasionally hired these folks to do training and intrusion audits. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Support
Grant Peel wrote: - Original Message - From: "Michael A. Peters" To: "Grant Peel" Cc: Sent: Sunday, March 29, 2009 10:00 PM Subject: Re: [PHP] Security Support Grant Peel wrote: Good Morning / Afternoon, We run several of our own servers: - Dell Power Edge 1U, Pentium, - FreeBSD (6.x soon to be 7.x) - along with all the standard Web Application installation (PHP Apache Exim, Pop3, Proftp, MySQL etc etc). What I am asking here, is if any one in this community has the knowledge to act as a security consultant in an occasional, as required basis. Anyone interested should have expience with Apache, PHP, Perl on the FreeBSD platform. No experience with FreeBSD and probably not enough with Perl - but whoever you hire, make sure they suggest your php build is hardened by suhosin - both the core php patch and the loadable module. Hi Again all, I am not sure what to make of all the chatter on this post To date, I have not recieved any sincere replies, which is a bit suprising. I am thinking that this job would be easy money for someone who already knows the ins and outs of php/Apache from a secuirty standpoint. I already have sohosin patch applied (it is applied as part of the default FreeBSD - php port). Anyways, the offer is still out there if anyone is interested. Nobody might have the right mix of skills you require (where-as going for a company if one person doesn't have the skills, someone else can take over). Probably quite a few people here could do the php and bsd but not the perl, or could do the php/perl but no idea about bsd (I fit into that category). -- Postgresql & php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Support
- Original Message - From: "Michael A. Peters" To: "Grant Peel" Cc: Sent: Sunday, March 29, 2009 10:00 PM Subject: Re: [PHP] Security Support Grant Peel wrote: Good Morning / Afternoon, We run several of our own servers: - Dell Power Edge 1U, Pentium, - FreeBSD (6.x soon to be 7.x) - along with all the standard Web Application installation (PHP Apache Exim, Pop3, Proftp, MySQL etc etc). What I am asking here, is if any one in this community has the knowledge to act as a security consultant in an occasional, as required basis. Anyone interested should have expience with Apache, PHP, Perl on the FreeBSD platform. No experience with FreeBSD and probably not enough with Perl - but whoever you hire, make sure they suggest your php build is hardened by suhosin - both the core php patch and the loadable module. Hi Again all, I am not sure what to make of all the chatter on this post To date, I have not recieved any sincere replies, which is a bit suprising. I am thinking that this job would be easy money for someone who already knows the ins and outs of php/Apache from a secuirty standpoint. I already have sohosin patch applied (it is applied as part of the default FreeBSD - php port). Anyways, the offer is still out there if anyone is interested. -Grant -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Support
I agree with you Daniel Regards, Igor Escobar systems analyst & interface designer www . igorescobar . com On Mon, Mar 30, 2009 at 10:58 AM, Daniel Brown wrote: > On Sun, Mar 29, 2009 at 22:07, abdulazeez alugo > wrote: > >> Yea, dude, well me GED says I kin git it dun wit less wastid time. > >> > >> -- > > No be only una get pidgin English ooo. Me sef fit do am sharp sharp no be > say them say. > > Is there any particular reason you guys totally trashed this > thread? It's fine if you don't want to apply, but please don't go out > of your way to try to make someone with a legitimate and > properly-formatted request look like a moron because it backfires > and reflects poorly on your own professionalism. > > -- > > daniel.br...@parasane.net || danbr...@php.net > http://www.parasane.net/ || http://www.pilotpig.net/ > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] Security Support
On Sun, Mar 29, 2009 at 22:07, abdulazeez alugo wrote: >> Yea, dude, well me GED says I kin git it dun wit less wastid time. >> >> -- > No be only una get pidgin English ooo. Me sef fit do am sharp sharp no be say > them say. Is there any particular reason you guys totally trashed this thread? It's fine if you don't want to apply, but please don't go out of your way to try to make someone with a legitimate and properly-formatted request look like a moron because it backfires and reflects poorly on your own professionalism. -- daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Support
> Date: Sun, 29 Mar 2009 19:02:15 -0700 > From: mpet...@mac.com > To: m...@hallmarcwebsites.com > CC: php-general@lists.php.net > Subject: Re: [PHP] Security Support > > Marc Christopher Hall wrote: > > I is a hi skool gradjuate > > Yea, dude, well me GED says I kin git it dun wit less wastid time. > > -- No be only una get pidgin English ooo. Me sef fit do am sharp sharp no be say them say. _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/
Re: [PHP] Security Support
Marc Christopher Hall wrote: I is a hi skool gradjuate Yea, dude, well me GED says I kin git it dun wit less wastid time. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Support
Grant Peel wrote: Good Morning / Afternoon, We run several of our own servers: - Dell Power Edge 1U, Pentium, - FreeBSD (6.x soon to be 7.x) - along with all the standard Web Application installation (PHP Apache Exim, Pop3, Proftp, MySQL etc etc). What I am asking here, is if any one in this community has the knowledge to act as a security consultant in an occasional, as required basis. Anyone interested should have expience with Apache, PHP, Perl on the FreeBSD platform. No experience with FreeBSD and probably not enough with Perl - but whoever you hire, make sure they suggest your php build is hardened by suhosin - both the core php patch and the loadable module. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Support
> From: da...@wonderly.com > To: defati...@hotmail.com; gp...@thenetnow.com; php-general@lists.php.net > Date: Sun, 29 Mar 2009 18:16:35 -0500 > Subject: Re: [PHP] Security Support > > > - Original Message - > From: "abdulazeez alugo" > To: ; > Sent: Sunday, March 29, 2009 6:09 PM > Subject: RE: [PHP] Security Support > > > > > > > > From: gp...@thenetnow.com > > To: php-general@lists.php.net > > Date: Sun, 29 Mar 2009 17:12:32 -0400 > > Subject: [PHP] Security Support > > > > Good Morning / Afternoon, > > > > We run several of our own servers: > > > > - Dell Power Edge 1U, Pentium, > > - FreeBSD (6.x soon to be 7.x) > > - along with all the standard Web Application installation (PHP Apache > > Exim, > > Pop3, Proftp, MySQL etc etc). > > > > What I am asking here, is if any one in this community has the knowledge > > to > > act as a security consultant in an occasional, as required basis. Anyone > > interested should have expience with Apache, PHP, Perl on the FreeBSD > > platform. > > > > We are more than willing to compensate for services rendered, and are more > > than willing to discuss terms. > > > > In the end, we would be more than willing to share any non-fudiciary > > information with anyone who could find it useful (via this or other > > mailing > > lists). > > > > We are asking any interested parties to contact us off-list such that we > > don't need to make any private matters public. > > > > This is a bonified request, as we can setup servers ourselves, but simply > > do > > not have the time to research various run time, and security related > > items. > > > > TIA, > > > > -Grant > > > Hey Guys, > > Let's be honest with ourselves here. If you've applied for this job, let me > see your hands up!!! > > > > Alugo Abdulazeez > > www.frangeovic.com > > > *Pauses and listens to crickets chirp* > > Dave Wonderly > WebGenero > www.webgenero.com Hey Dave, Are you trying to tell us something or are you just writing your first novel? Alugo Abdulazeez _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx
RE: [PHP] Security Support
I is a hi skool gradjuate -Original Message- From: abdulazeez alugo [mailto:defati...@hotmail.com] Sent: Sunday, March 29, 2009 7:10 PM To: gp...@thenetnow.com; php-general@lists.php.net Subject: RE: [PHP] Security Support > From: gp...@thenetnow.com > To: php-general@lists.php.net > Date: Sun, 29 Mar 2009 17:12:32 -0400 > Subject: [PHP] Security Support > > Good Morning / Afternoon, > > We run several of our own servers: > > - Dell Power Edge 1U, Pentium, > - FreeBSD (6.x soon to be 7.x) > - along with all the standard Web Application installation (PHP Apache Exim, > Pop3, Proftp, MySQL etc etc). > > What I am asking here, is if any one in this community has the knowledge to > act as a security consultant in an occasional, as required basis. Anyone > interested should have expience with Apache, PHP, Perl on the FreeBSD > platform. > > We are more than willing to compensate for services rendered, and are more > than willing to discuss terms. > > In the end, we would be more than willing to share any non-fudiciary > information with anyone who could find it useful (via this or other mailing > lists). > > We are asking any interested parties to contact us off-list such that we > don't need to make any private matters public. > > This is a bonified request, as we can setup servers ourselves, but simply do > not have the time to research various run time, and security related items. > > TIA, > > -Grant Hey Guys, Let's be honest with ourselves here. If you've applied for this job, let me see your hands up!!! Alugo Abdulazeez www.frangeovic.com _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx __ Information from ESET Smart Security, version of virus signature database 3973 (20090329) __ The message was checked by ESET Smart Security. http://www.eset.com __ Information from ESET Smart Security, version of virus signature database 3973 (20090329) __ The message was checked by ESET Smart Security. http://www.eset.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Support
- Original Message - From: "abdulazeez alugo" To: ; Sent: Sunday, March 29, 2009 6:09 PM Subject: RE: [PHP] Security Support From: gp...@thenetnow.com To: php-general@lists.php.net Date: Sun, 29 Mar 2009 17:12:32 -0400 Subject: [PHP] Security Support Good Morning / Afternoon, We run several of our own servers: - Dell Power Edge 1U, Pentium, - FreeBSD (6.x soon to be 7.x) - along with all the standard Web Application installation (PHP Apache Exim, Pop3, Proftp, MySQL etc etc). What I am asking here, is if any one in this community has the knowledge to act as a security consultant in an occasional, as required basis. Anyone interested should have expience with Apache, PHP, Perl on the FreeBSD platform. We are more than willing to compensate for services rendered, and are more than willing to discuss terms. In the end, we would be more than willing to share any non-fudiciary information with anyone who could find it useful (via this or other mailing lists). We are asking any interested parties to contact us off-list such that we don't need to make any private matters public. This is a bonified request, as we can setup servers ourselves, but simply do not have the time to research various run time, and security related items. TIA, -Grant Hey Guys, Let's be honest with ourselves here. If you've applied for this job, let me see your hands up!!! Alugo Abdulazeez www.frangeovic.com _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx *Pauses and listens to crickets chirp* Dave Wonderly WebGenero www.webgenero.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Security Support
> From: gp...@thenetnow.com > To: php-general@lists.php.net > Date: Sun, 29 Mar 2009 17:12:32 -0400 > Subject: [PHP] Security Support > > Good Morning / Afternoon, > > We run several of our own servers: > > - Dell Power Edge 1U, Pentium, > - FreeBSD (6.x soon to be 7.x) > - along with all the standard Web Application installation (PHP Apache Exim, > Pop3, Proftp, MySQL etc etc). > > What I am asking here, is if any one in this community has the knowledge to > act as a security consultant in an occasional, as required basis. Anyone > interested should have expience with Apache, PHP, Perl on the FreeBSD > platform. > > We are more than willing to compensate for services rendered, and are more > than willing to discuss terms. > > In the end, we would be more than willing to share any non-fudiciary > information with anyone who could find it useful (via this or other mailing > lists). > > We are asking any interested parties to contact us off-list such that we > don't need to make any private matters public. > > This is a bonified request, as we can setup servers ourselves, but simply do > not have the time to research various run time, and security related items. > > TIA, > > -Grant Hey Guys, Let's be honest with ourselves here. If you've applied for this job, let me see your hands up!!! Alugo Abdulazeez www.frangeovic.com _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx
Re: [PHP] Security question
Frank Stanovcak wrote: > "VamVan" wrote in message > news:12eb8b030901141421u6741b943q396bc784136b7...@mail.gmail.com... > >> On Wed, Jan 14, 2009 at 2:22 PM, Frank Stanovcak >> wrote: >> >> >>> This is mostly to make sure I understand how sessions are handled >>> correctly. >>> As far as sessions are concerned the variable data is stored on the >>> server >>> (be it in memory or temp files), and never transmitted accross the net >>> unless output to the page? So this means I should be able to store the >>> username and password for a program in session vars for quick >>> validations, >>> and if I force rentry of the password for sensitive areas (every time) >>> even >>> if someone mannages to spoof the sesid all they will have access to is >>> non >>> sensitive areas? This also assumes I, at least, quick validate at the >>> start >>> of every page immideately after starting the session. >>> >>> >>> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >>> >> Password should never be stored anywhere in clear text. You can store md5 >> version in session or database. As long as password is encrypted ure fine >> and safe. >> >> Thanks, >> V >> >> > > Thanks V > So if I store the hash in the db, and in the session var then I should be > resonably safe provided I salt the hash prior to storing it? > > > > Yes, but don't use md5. There are lookups available to help someone crack it. Try sha1: http://us3.php.net/sha1 Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security question
"VamVan" wrote in message news:12eb8b030901141421u6741b943q396bc784136b7...@mail.gmail.com... > On Wed, Jan 14, 2009 at 2:22 PM, Frank Stanovcak > wrote: > >> This is mostly to make sure I understand how sessions are handled >> correctly. >> As far as sessions are concerned the variable data is stored on the >> server >> (be it in memory or temp files), and never transmitted accross the net >> unless output to the page? So this means I should be able to store the >> username and password for a program in session vars for quick >> validations, >> and if I force rentry of the password for sensitive areas (every time) >> even >> if someone mannages to spoof the sesid all they will have access to is >> non >> sensitive areas? This also assumes I, at least, quick validate at the >> start >> of every page immideately after starting the session. >> >> >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > Password should never be stored anywhere in clear text. You can store md5 > version in session or database. As long as password is encrypted ure fine > and safe. > > Thanks, > V > Thanks V So if I store the hash in the db, and in the session var then I should be resonably safe provided I salt the hash prior to storing it? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security question
On Wed, Jan 14, 2009 at 2:22 PM, Frank Stanovcak wrote: > This is mostly to make sure I understand how sessions are handled > correctly. > As far as sessions are concerned the variable data is stored on the server > (be it in memory or temp files), and never transmitted accross the net > unless output to the page? So this means I should be able to store the > username and password for a program in session vars for quick validations, > and if I force rentry of the password for sensitive areas (every time) even > if someone mannages to spoof the sesid all they will have access to is non > sensitive areas? This also assumes I, at least, quick validate at the > start > of every page immideately after starting the session. > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Password should never be stored anywhere in clear text. You can store md5 version in session or database. As long as password is encrypted ure fine and safe. Thanks, V
Re: [PHP] security and database
On 11 Oct 2008, at 20:18, Alain Roger wrote: to have access to my web application, user needs to log in. Before to send login/password over the net, user is directly redirected to HTTPS version of my web application in case he did not write HTTPS:// at the address bar. once he types login/password, everything is checked with DB data and if it is correct, so he's granted right to continue and he redirected to another HTTPS web page. i would like improve security but i'm not sure it make sense as HTTPS is used. SSL secures the data transmission from client to server and there's nothing currently available that provides better security at that level. therefore i was thinking to request for each stored procedures (all my SQL requests are in stored procedures) login and password (stored into session)... but does it make really sense ? First of all, IMHO there are no valid reasons for storing passwords in the session. If you think you have one I'm betting your architecture is either overly complicated or just plain wrong. Secondly, I see no security advantage in requiring a username and password to be passed along with each stored procedure request. Aside from the extra overhead, if someone gets access to your database you have other problems which won't be solved by requiring a username and password to execute stored procedures. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
At 10:55 PM +0100 9/22/08, Ashley Sheridan wrote: Who is /dev/null, and what does he advertise? ;) Nothing. Get it? 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] Security warning
At 5:48 PM -0400 9/22/08, Daniel Brown wrote: On Mon, Sep 22, 2008 at 5:45 PM, tedd <[EMAIL PROTECTED]> wrote: The problem here is that the site is pretty large (>100 pages) and has thousands of members. I think they would notice a slow down, but that's one of the things they are considering. A site like that should probably already be load-balancing anyway. Now if only there were someone here who provided such services There's only one problem -- that makes sense. The project I've been working on for over a year doesn't. 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] Security warning
On Mon, Sep 22, 2008 at 6:02 PM, Daniel Brown <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 5:55 PM, Eric Butera <[EMAIL PROTECTED]> wrote: >> >> That reply was just another attempt at getting your sig into the archives. >> :P > >It wasn't, but good point, Butera. ;-P > > -- > > [Deleted from this email for everyone's sake. The Earth is running > out of bandwidth!] > Hehe :D -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
On Mon, Sep 22, 2008 at 5:55 PM, Eric Butera <[EMAIL PROTECTED]> wrote: > > That reply was just another attempt at getting your sig into the archives. :P It wasn't, but good point, Butera. ;-P -- [Deleted from this email for everyone's sake. The Earth is running out of bandwidth!] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
On Mon, Sep 22, 2008 at 5:50 PM, Daniel Brown <[EMAIL PROTECTED]> wrote: >ATTENTION LAWYERS AND THREAD-FLAMERS: > >That was meant to be a "reply" to Tedd personally, not a > "reply-all." Anyone wishing to slam me for advertising is welcome to > email your local /dev/null. > > -- > > More full-root dedicated server packages: > Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. > Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. > Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo. > Dedicated servers, VPS, and hosting from $2.50/mo. That reply was just another attempt at getting your sig into the archives. :P -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
On Mon, 2008-09-22 at 17:50 -0400, Daniel Brown wrote: > On Mon, Sep 22, 2008 at 5:48 PM, Daniel Brown <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 22, 2008 at 5:45 PM, tedd <[EMAIL PROTECTED]> wrote: > >> > >> The problem here is that the site is pretty large (>100 pages) and has > >> thousands of members. I think they would notice a slow down, but that's one > >> of the things they are considering. > > > >A site like that should probably already be load-balancing anyway. > > Now if only there were someone here who provided such services > > ATTENTION LAWYERS AND THREAD-FLAMERS: > > That was meant to be a "reply" to Tedd personally, not a > "reply-all." Anyone wishing to slam me for advertising is welcome to > email your local /dev/null. > > -- > > More full-root dedicated server packages: > Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. > Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. > Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo. > Dedicated servers, VPS, and hosting from $2.50/mo. > Who is /dev/null, and what does he advertise? ;) Ash www.ashleysheridan.co.uk
Re: [PHP] Security warning
On Mon, Sep 22, 2008 at 5:48 PM, Daniel Brown <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 5:45 PM, tedd <[EMAIL PROTECTED]> wrote: >> >> The problem here is that the site is pretty large (>100 pages) and has >> thousands of members. I think they would notice a slow down, but that's one >> of the things they are considering. > >A site like that should probably already be load-balancing anyway. > Now if only there were someone here who provided such services ATTENTION LAWYERS AND THREAD-FLAMERS: That was meant to be a "reply" to Tedd personally, not a "reply-all." Anyone wishing to slam me for advertising is welcome to email your local /dev/null. -- More full-root dedicated server packages: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
On Mon, Sep 22, 2008 at 5:45 PM, tedd <[EMAIL PROTECTED]> wrote: > > The problem here is that the site is pretty large (>100 pages) and has > thousands of members. I think they would notice a slow down, but that's one > of the things they are considering. A site like that should probably already be load-balancing anyway. Now if only there were someone here who provided such services -- More full-root dedicated server packages: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
At 11:22 PM +0200 9/22/08, Jochem Maas wrote: my personal theory on this is do *everything* via https, screw the overhead and buy a bigger box ... given the state of the art it won't be *that* long before pretty much everything site handling forms/transactions/etc use https exclusively. besides which always having the funky little lock in the status bar canb be [stupidly?] reassuring the the average user. The problem here is that the site is pretty large (>100 pages) and has thousands of members. I think they would notice a slow down, but that's one of the things they are considering. 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] Security warning
tedd schreef: At 4:34 PM -0400 9/22/08, Daniel Brown wrote: On Mon, Sep 22, 2008 at 2:48 PM, tedd <[EMAIL PROTECTED]> wrote: > However, when the user exits https and returns back to the http side of > things, the user receives a warning. If the error you're getting is just saying that you're being redirected from a secure to an insecure site, that's based on browser security, which - thank God - is not a(n easily) changeable thing from the 'Net. Daniel: That's it exactly. The client saw this warning in FF but not in Safari and wanted me to turn it off. I told him the reason I thought, which you just confirmed, but I wanted to be sure. I can't remember where I read about it but the warning is probably due to the vulnerability inherent with having a cookie available via https *and* http. just for kick you might try regenerating the session id just before you move them off the https page ... doubt that will have an effect though. you might consider using seperate cookies for https and http and using a special redirector script to move the user from http to https (passing along a SID like identifier to use as a matching mechanism for the 2 cookies/sessions), obviously ... I feel that this is going to be a step backwards in terms of security. lastly you might try viewing headers (liveheaders) of a site that seems to do the same (but without the warning) my personal theory on this is do *everything* via https, screw the overhead and buy a bigger box ... given the state of the art it won't be *that* long before pretty much everything site handling forms/transactions/etc use https exclusively. besides which always having the funky little lock in the status bar canb be [stupidly?] reassuring the the average user. Thanks, tedd -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
At 4:34 PM -0400 9/22/08, Daniel Brown wrote: On Mon, Sep 22, 2008 at 2:48 PM, tedd <[EMAIL PROTECTED]> wrote: > However, when the user exits https and returns back to the http side of > things, the user receives a warning. If the error you're getting is just saying that you're being redirected from a secure to an insecure site, that's based on browser security, which - thank God - is not a(n easily) changeable thing from the 'Net. Daniel: That's it exactly. The client saw this warning in FF but not in Safari and wanted me to turn it off. I told him the reason I thought, which you just confirmed, but I wanted to be sure. Thanks, 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] Security warning
On Mon, 2008-09-22 at 16:55 -0400, tedd wrote: > At 8:49 PM +0100 9/22/08, Ashley Sheridan wrote: > >On Mon, 2008-09-22 at 14:48 -0400, tedd wrote: > > > > > I suspect that the purpose of this warning is to alert the user when > >> they are taken from a https directory to a http directory. > >> > >> Now my question is "Can I turn off that security warning?" or find a > > > way around it? > > > > > > >I think that warning is built into the browsers that recognise you are > >moving from to a non-secure version of the same domain. If you give your > >users some kind of hint that this may happen it should alleviate their > >fears. > > Ash: > > That's what I suspected and told the client -- however, the client > seems to think there should be a way to turn that off. > > I told the client that it was a browser thing to help protect users > and stop evil-programmers from taking the user from a secured site to > an unsecured site without telling the user. But, I just wanted to > have my understanding confirmed. > > Thanks, > > tedd > > I think it can be turned off on the browser in question, so you could turn it off on your clients browser and stop them making silly requests ;) Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
At 8:49 PM +0100 9/22/08, Ashley Sheridan wrote: On Mon, 2008-09-22 at 14:48 -0400, tedd wrote: > I suspect that the purpose of this warning is to alert the user when they are taken from a https directory to a http directory. Now my question is "Can I turn off that security warning?" or find a > way around it? > I think that warning is built into the browsers that recognise you are moving from to a non-secure version of the same domain. If you give your users some kind of hint that this may happen it should alleviate their fears. Ash: That's what I suspected and told the client -- however, the client seems to think there should be a way to turn that off. I told the client that it was a browser thing to help protect users and stop evil-programmers from taking the user from a secured site to an unsecured site without telling the user. But, I just wanted to have my understanding confirmed. Thanks, 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] Security warning
On Mon, Sep 22, 2008 at 2:48 PM, tedd <[EMAIL PROTECTED]> wrote: > Hi gang: > > I have a problem (please, no remarks). :-) > > I have a site where a security certificate is in place and it works. The > user can login and review their information and purchase stuff. When the > user goes from the http to the https side of things, everything is fine -- > their no warning given and the user can enter their cc information, buy > stuff, and everything appears secure. > > However, when the user exits https and returns back to the http side of > things, the user receives a warning. Unless the SSL certificate is using wildcard DNS for its domain, an error will be issued if you switch, say, from `www.example.com` to `example.com`. If the error you're getting is just saying that you're being redirected from a secure to an insecure site, that's based on browser security, which - thank God - is not a(n easily) changeable thing from the 'Net. -- More full-root dedicated server packages: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security warning
On Mon, 2008-09-22 at 14:48 -0400, tedd wrote: > Hi gang: > > I have a problem (please, no remarks). :-) > > I have a site where a security certificate is in place and it works. > The user can login and review their information and purchase stuff. > When the user goes from the http to the https side of things, > everything is fine -- their no warning given and the user can enter > their cc information, buy stuff, and everything appears secure. > > However, when the user exits https and returns back to the http side > of things, the user receives a warning. > > I suspect that this is because I am continuing to keep the user > logged in -- in other words, I'm keeping an authorization session in > effect. I say this because, when I don't do that, the security > warning isn't thrown. > > I suspect that the purpose of this warning is to alert the user when > they are taken from a https directory to a http directory. > > Now my question is "Can I turn off that security warning?" or find a > way around it? > > I want the user after purchasing an item to return to the normal http > side of things and still be logged on -- how do you guys do it? > > Thanks, > > tedd > > -- > --- > http://sperling.com http://ancientstones.com http://earthstones.com > I think that warning is built into the browsers that recognise you are moving from to a non-secure version of the same domain. If you give your users some kind of hint that this may happen it should alleviate their fears. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Concern?
On Apr 21, 2008, at 1:46 PM, Jason Pruim wrote: On Apr 21, 2008, at 11:49 AM, Philip Thompson wrote: On Apr 21, 2008, at 8:03 AM, Jason Pruim wrote: Hi Everyone, Last week you all helped me with the code to pull the database field names directly from the database rather then being hardcoded by me. Now I got to thinking, that I have exposed my database layout to anyone who can log in and see it. Is that a security issue? I've heard that if an attacker has the field names of a database, it makes it easier for them to try and inject code into it. All my queries to the database are done through prepared statements, and mysqli_real_escape_string. So I've taken care of at least part of it. I'm thinking that sense you have to log into the website to see the field names, it's okay as long as I trust and monitor my users. But I thought I would pose the question to people who are ALOT more knowledgeable then me :) Any comments are welcome, if you want to see source let me know and I can shoot you an e-mail off list (Don't really want to expose my code to all the archives just yet :)) As long as you're taking the necessary measures to ensure that your database is not breakable/hackable, then us knowing your schema shouldn't be an issue. I'd bet that one could guess part (or all?) of many people's database schemas b/c they're so generic - and it doesn't really matter to obfuscate them. I don't think it's as important to create obscure database schemas as it is protect how you interact with it. However, just make sure of the following, and you should be good: • Use mysql?_real_escape_string as you mentioned • Use `backticks` around ALL your table and field names: $sql = "SELECT `first_name`, `last_name` FROM `user` WHERE (`user_id` = '$user_id')"; ?> With those simple precautions, you should be well-protected. Hey Phillip, Thanks for the response, I'll have to double check if I have the back ticks around my field names... On top of it being for security reasons, it's good to use them so you won't having a naming conflict with RESERVED words. One time I scratched my head for a while trying to figure out why my script with sql wasn't working. Eventually I figured out that I named one of my fields the same thing as a reserved word. Well, MySQL didn't really like that. Using backticks *fixed* the problem. HTH, ~Philip PS: I try not to use reserved words as field names anymore since some consider it *bad practice*! =P And to complete the archives, I was recommend a couple of books by Chris Shiftlett Here's the link for anyone who is interested: http://shiflett.org/books Thanks again for the response! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Concern?
On Apr 21, 2008, at 11:49 AM, Philip Thompson wrote: On Apr 21, 2008, at 8:03 AM, Jason Pruim wrote: Hi Everyone, Last week you all helped me with the code to pull the database field names directly from the database rather then being hardcoded by me. Now I got to thinking, that I have exposed my database layout to anyone who can log in and see it. Is that a security issue? I've heard that if an attacker has the field names of a database, it makes it easier for them to try and inject code into it. All my queries to the database are done through prepared statements, and mysqli_real_escape_string. So I've taken care of at least part of it. I'm thinking that sense you have to log into the website to see the field names, it's okay as long as I trust and monitor my users. But I thought I would pose the question to people who are ALOT more knowledgeable then me :) Any comments are welcome, if you want to see source let me know and I can shoot you an e-mail off list (Don't really want to expose my code to all the archives just yet :)) As long as you're taking the necessary measures to ensure that your database is not breakable/hackable, then us knowing your schema shouldn't be an issue. I'd bet that one could guess part (or all?) of many people's database schemas b/c they're so generic - and it doesn't really matter to obfuscate them. I don't think it's as important to create obscure database schemas as it is protect how you interact with it. However, just make sure of the following, and you should be good: • Use mysql?_real_escape_string as you mentioned • Use `backticks` around ALL your table and field names: $sql = "SELECT `first_name`, `last_name` FROM `user` WHERE (`user_id` = '$user_id')"; ?> With those simple precautions, you should be well-protected. Hey Phillip, Thanks for the response, I'll have to double check if I have the back ticks around my field names... And to complete the archives, I was recommend a couple of books by Chris Shiftlett Here's the link for anyone who is interested: http://shiflett.org/books Thanks again for the response! -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security Concern?
On Apr 21, 2008, at 8:03 AM, Jason Pruim wrote: Hi Everyone, Last week you all helped me with the code to pull the database field names directly from the database rather then being hardcoded by me. Now I got to thinking, that I have exposed my database layout to anyone who can log in and see it. Is that a security issue? I've heard that if an attacker has the field names of a database, it makes it easier for them to try and inject code into it. All my queries to the database are done through prepared statements, and mysqli_real_escape_string. So I've taken care of at least part of it. I'm thinking that sense you have to log into the website to see the field names, it's okay as long as I trust and monitor my users. But I thought I would pose the question to people who are ALOT more knowledgeable then me :) Any comments are welcome, if you want to see source let me know and I can shoot you an e-mail off list (Don't really want to expose my code to all the archives just yet :)) As long as you're taking the necessary measures to ensure that your database is not breakable/hackable, then us knowing your schema shouldn't be an issue. I'd bet that one could guess part (or all?) of many people's database schemas b/c they're so generic - and it doesn't really matter to obfuscate them. I don't think it's as important to create obscure database schemas as it is protect how you interact with it. However, just make sure of the following, and you should be good: • Use mysql?_real_escape_string as you mentioned • Use `backticks` around ALL your table and field names: $sql = "SELECT `first_name`, `last_name` FROM `user` WHERE (`user_id` = '$user_id')"; ?> With those simple precautions, you should be well-protected. HTH, ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Security scanner
On Mon, February 11, 2008 9:27 am, Emil Edeholt wrote: > Thanks. Sure, I know how to escape and filter the input.. But since > not > all my sites use PDO yet, and I use some external code it would be a > good idea to also use an sql injection scanner. Scanning for SQL injection is like a "blacklist" approach -- always bound to be another injection you didn't think of. Validating the data and using mysql_real_escape_string is the "whitelist" approach -- You specifically require the data to be of the correct format, and you get MySQL to delimit it properly as DATA and not SQL CODE. -- 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/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
