Timeline for What is the next step of this file upload attack?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 14, 2013 at 16:13 | history | edited | Manishearth | CC BY-SA 3.0 |
added 236 characters in body
|
| Mar 14, 2013 at 16:11 | comment | added | Manishearth | @mehaase: By that I meant that HTTP can only send and receive messages, which have no direct effect on the filesystem. PHP can wreak havoc with the filesystem if told to. | |
| Mar 14, 2013 at 16:09 | comment | added | Manishearth | @mehaase: Fine. Assume that mod-php is a registered handler for .jpg. So? Until the attacker coaxes PHP to run that file, he can't do anything. I've addressed AJHs point about "giving a path" in my last paragraph, though I probably ought to expand that a bit. | |
| Mar 14, 2013 at 16:06 | comment | added | Mark E. Haase | "PHP is run with permissions that can't be obtained by a hacker via normal HTTP." I'm not sure if this is true for IIS in particular, but it's definitely not true in general. E.g. when running mod-php with apache, mod-php runs inside the daemon processes, and therefore executes as the same user, same umask, etc. | |
| Mar 14, 2013 at 16:04 | comment | added | Mark E. Haase | "As long as you have control over the file name and where it's stored1, it's not an issue." Wrong. See AJ Henderson's post, and also consider what happens if mod-php is a registered handler for .jpg files. | |
| Mar 14, 2013 at 15:58 | history | edited | Manishearth | CC BY-SA 3.0 |
added 39 characters in body
|
| Mar 13, 2013 at 19:49 | history | answered | Manishearth | CC BY-SA 3.0 |