Re: [PHP] Security Issue

2010-06-08 Thread Michael Shadle
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

2010-06-08 Thread David Stoltz
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

2010-06-08 Thread Igor Escobar
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

2010-06-07 Thread Raymond Irving
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

2010-06-07 Thread richard gray

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

2010-06-07 Thread Bob McConnell
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

2010-06-07 Thread 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.
> 
> 
> 
> // 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

2010-06-07 Thread Michael Shadle
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

2010-06-07 Thread Igor Escobar
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

2010-06-07 Thread Igor Escobar
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

2010-06-07 Thread Michael Shadle
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

2010-06-07 Thread Michael Shadle
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

2010-06-07 Thread Igor Escobar
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

2010-06-07 Thread Ashley Sheridan
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

2010-06-07 Thread Ashley Sheridan
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

2010-06-07 Thread Michael Shadle
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

2010-06-07 Thread Ashley Sheridan
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

2010-06-07 Thread Igor Escobar
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

2010-06-07 Thread Michael Shadle

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

2010-06-07 Thread Bob McConnell
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

2010-06-07 Thread Igor Escobar
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

2010-06-07 Thread Igor Escobar
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

2010-06-07 Thread Igor Escobar
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

2010-06-07 Thread Phpster


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

2010-06-07 Thread Peter Lind
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

2010-06-07 Thread Ashley Sheridan
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

2007-09-05 Thread Instruct ICC
It was able to call up external includes using the below code which 
resulted

that the server was used to send out spam.
How can I protect the code?


Is ../inc/ in the web path?  $_SERVER['DOCUMENT_ROOT']

If so, then what do you mean by "external includes"?  You need to move inc/ 
to a path unreachable by a browser yet reachable by PHP.


_
Test your celebrity IQ.  Play Red Carpet Reveal and earn great prizes! 
http://club.live.com/red_carpet_reveal.aspx?icid=redcarpet_hotmailtextlink2


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Security Issue

2007-09-04 Thread Wouter van Vliet / Interpotential
Karl,

Some simple checks on $contpath could solve your problem. Make sure that:

 - it doesn't start with a /
 - doesn't contain /../
 - it doesn't contain a double slash //, or make sure the URL Fopen wrapper
is disabled:
http://nl3.php.net/manual/en/ref.filesystem.php#ini.allow-url-fopen

Usually $contpath = str_replace('/', '', $contpath); takes care of
everything.

On 04/09/07, Karl-Heinz Schulz <[EMAIL PROTECTED]> wrote:
>
>  It was able to call up external includes using the below code which
> resulted that the server was used to send out spam.
>
> How can I protect the code?
>
> TIA
>
> 
> session_start();
>
>
> //---
>
> // index.php
>
>
> //---
>
> include("../inc/const.php");
>
> include("../inc/mysql.php");
>
>  $menu=2;
>
> include("../inc/static.php");
>
> //include("../inc/prolog.php");
>
> $base = getenv("SERVER_NAME").getenv("SCRIPT_NAME");
>
> //$menu = $HTTP_GET_VARS['menu'];
>
> $submenu_list = $HTTP_GET_VARS['submenu_list'];
>
> $contfile = $HTTP_GET_VARS['contfile'];
>
> $id = $HTTP_GET_VARS['id'];
>
> $stk = $HTTP_GET_VARS['stk'];
>
> $contpath = $HTTP_GET_VARS['contpath'];
>
> if ($contpath=="")
>
> { $contpath="./"; }
>
> ?>
>
> 
>
> 
>
> Neuer Wissenschaftlicher Verlag -  $typ_subnav[$menu]?>
>
> 
>
> 
>
> 
>
>  marginwidth="0" link="#00" vlink="#00" alink="#00">
>
>  cellpadding="0" border="0">
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
>  background="../../img_pool/bg_left_right.gif"> include("../inc/leftmenu.php");?>
>
>  
>
> 
>
> 
>
> 
>
> 
>
>  background="../../img_pool/bg_left_right.gif">
>
> 
>
> //
>
>   //  Subnavigation
>
>
> //
>
> include("../inc/subnav.php");
>
> ?>
>
> 
>
> 
>
>  
>
>  
>
> 
>
>  
>
>
>
>  
>  ?>
>
>   
>
>  
>
>
>
>  
>
>
>
> 
>
>


-- 
Interpotential.com
Phone: +31615397471


Re: [PHP] Security Issue

2001-04-03 Thread Michael Kimsal

Not really sure what you need suggestions on.  There are tons
of examples for querying MySQL databases from PHP out
there around the net, not to mention the php.net mysql
area itself.



Scott Novinger wrote:

> Hello,
>
> Would someone please offer some specific suggestions for the following?:
>
> 1.  I have several static web pages ready to be published on the
> internet.
>
> 2.  We have chosed PHP, MySQL and Apache as part of our development
> system.
>
> 3.  I would like to incorporate a PHP script into each static web page
> that queries a MySQL database.  This script will determine whether or
> not the person trying to view the page has the proper security
> privledges.
>
> If I need to explain this problem in more detail, please let me know.
> Any help or suggestions are greatly appreciated.

Unfortunately, you've not really given any amount of detail at all,
beyond describing about every web-based application out there
(aside from the PHP aspect of it).

You need to determine what the criteria are for determining security
privileges.
Translate those criteria into fields in a database.
Also translate the logic into PHP code.

That's about it.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP] Security Issue

2001-04-03 Thread Rasmus Lerdorf

> 1.  I have several static web pages ready to be published on the
> internet.

Great

> 2.  We have chosed PHP, MySQL and Apache as part of our development
> system.

Ok

> 3.  I would like to incorporate a PHP script into each static web page
> that queries a MySQL database.  This script will determine whether or
> not the person trying to view the page has the proper security
> privledges.

Cool, do it.  It's trivial.

-Rasmus


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]