Nice topic! A cool exploit I used for some security test was an hidden upload form used as backdoor to upload PHP files, in combination with this phpinstaller<https://github.com/rainphp/phpinstaller>, I was able to compress all files in a single auto-deflating PHP and upload on the website.
If you want to check the security of an application you may want to keep an eye also on file_get_contents, curl and "simple" input form. On Wed, Nov 9, 2011 at 9:58 AM, Gary Mort <garyam...@gmail.com> wrote: > On 10/20/2011 5:10 PM, Chris Snyder wrote: > >> It would be more interesting to find out that these attacks are happening >> in VPSes or private servers, which would indicated a real exploit, rather >> than on GoDaddy or Dreamhost or some other shared system. >> > > I find there are 3 classifications of attacks to be concerned about, and > each is problematic to address. > > One is known PHP exploits. The problem with known PHP exploits is that > there are a number of ways to secure a system against them, but quite often > PHP programmers have this idealized view that basically shifts the > responsibility for security to the underlying operating system. There are > quite a number of exploits based on writing or appending to an existing > file where if the file was read only, even if still owned by the web server > process and able to chmod it at will from within PHP, those exploits would > be stopped cold. Coders are lazy though and they claim "well, if you can > WRITE to the file, then you can change the file permissions, so why should > I do extra work whenever I want to write a file". > > The next is based on shared hosts and leaving files writable to other > virtual hosts running on the system, so one compromise allows all to be > compromised. Instead of taking steps to minimize that, the solution > proposed seems to be run your own VPS. > > Yet the VPS has it's own problem in that most of them don't bother to lock > out users who repeatedly try to ftp/sftp to the system - thereby being open > to dictionary attacks. > > The solution is to take security seriously and actually attempt to plug as > many holes as possible, never just declare it as someone else's problem and > that "all will be better if only you do..." > > Just MHO > > -Gary > > ______________________________**_________________ > New York PHP Users Group Community Talk Mailing List > http://lists.nyphp.org/**mailman/listinfo/talk<http://lists.nyphp.org/mailman/listinfo/talk> > > http://www.nyphp.org/Show-**Participation<http://www.nyphp.org/Show-Participation> >
_______________________________________________ New York PHP Users Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/Show-Participation
