[WEB SECURITY] AT&T exposes /etc/passwd , bad php

[Matt Parsons]

I wonder if AT&T did a security review of this application.  If you had one
of the leading vendor tools you could have done a source code analysis of
the code in php and prevent this from happening.   In the future, companies
like AT&T should consider reviewing their PHP code from both a white box and
black box.  At a minimum, I would consider making sure there was proper
permissions on that file.   Personally, I would have written the application
in a language that is a bit more secure like .NET or Java.   

 

Matt

 

 

Matt Parsons, CISSP

315-559-3588 Blackberry

817-238-3325 Home office 

mparsons1980 at gmail.com

www.parsonsisconsulting.com 

 

CISSP_logo

 

From: Kevin Stewart [mailto:kevin.g.stewart at gmail.com] 
Sent: Monday, July 27, 2009 6:21 PM
To: Michael Condon
Cc: Shane Forsythe; websecurity at webappsec.org
Subject: Re: [WEB SECURITY] AT&T exposes /etc/passwd , bad php

 

By the way, the AT&T url breaks semantics by allowing a write condition in a
GET request. Not that leaving an open ended "page=" in a form post would
have been any better...

Kevin S.

On Mon, Jul 27, 2009 at 7:19 PM, Kevin Stewart <kevin.g.stewart at gmail.com>
wrote:

It is semantically correct to use a GET (and querystring) when the request
will not write or change data. 

(see: http://www.w3.org/2001/tag/doc/whenToUseGet.html).

At a minimum though, you cannot bookmark POST requests and their responses
are usually not cached - two very important performance and usability
considerations.

Kevin S.





On Mon, Jul 27, 2009 at 4:11 PM, Michael Condon
<admin at singulartechnologysolutions.com> wrote:

Can anyone convince me (or anyone else) why I should ever use a QUERY_STRING
in a URL?


-----Original Message-----
From: Shane Forsythe [mailto:shane.forsythe at fau.edu]
Sent: Monday, July 27, 2009 1:09 PM
To: websecurity at webappsec.org
Subject: [WEB SECURITY] AT&T exposes /etc/passwd , bad php

In an amazing example of how not to do file operations with php.  AT&T
has the following URL

http://www.research.att.com/areas/visualization/papers_videos/subpage.php?pa
ge=

You can add ANY file to the end and will happily retrieve for you,
though I'd suggest not actually testing it out
(some examples that were vurnable)
../../../../proc/cpuinfo
/etc/passwd

It appears they have taken page offload and our now aware of it, but if
you follow the comments here, it was active for a good portion and
thoroughly combed over
http://www.reddit.com/r/programming/comments/94z5w/att_exposes_etcpasswd_bad
<http://www.reddit.com/r/programming/comments/94z5w/att_exposes_etcpasswd_ba
d%0A_php/> 
_php/


This seems to be an escalating of AT&T event regarding 4chan






----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA





-- 
Kevin G. Stewart




-- 
Kevin G. Stewart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090727/a3f6dd63/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 2509 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090727/a3f6dd63/attachment.jpg>