Talk:File inclusion vulnerability/Archive 1

Archive 1

Gents, For me, the RFI "attack" (1) works more because of fopen() wrappers being On and inpout data not being sanitized/cleaned than because of register_globals=On. Being a PHP guru, I still recommend to use register_globals=On and I'm no fool. My scripts were never penetrated by attacks such as XSS, RFI... I recommend correcting the wiki page. register_globals=On is not the main culprit in succeeding RFI attacks. Having register_globals=Off, the same people would probably not validate the $_GET[] or $_POST[] data either... Security is to be taught and learnt. Tips : RTFM for addslashes(), urlencode() and urldecode(), strip_tags(), str_replace() and why not eval()

If those "programmers" had begun learning programming with compiled languages and strict teachers, they would not do such stupid mistakes like not validating user input data.

Regards, VGR

---

www.europeanexperts.org

(1) it's more a vulnerability test to me than a real attack, when the included file is a .txt file for instance ; from my log files I see 99.99% of the included files are non-executable ones (.txt mainly).

82.243.20.181 07:00, 21 August 2007 (UTC)

I agree: disabling register_globals accomplishes nothing, besides maybe breaking the original script (which you could call a fix for the problem, the user probably won't). What you should do is either disable allow_url_fopen (php4) and allow_url_include (php5). These settings really prevent php from fetching remote content.

(1) it's more a vulnerability test to me than a real attack, when the included file is a .txt file for instance ; from my log files I see 99.99% of the included files are non-executable ones (.txt mainly).

It does not matter what "filetype" the included file has, the php interpreter will interpret it. foo.txt, bar.php, girl.jpg doesn't matter.

Tinnet 17:07, 23 August 2007 (UTC)

legacy style

This article makes it seem like only the legacy style with register globals can be vulnerable, that is obviously not the case. Further, the article just plain ignores other languages then php, this is not some php only wiki, this is wikipedia. In addition, it should at least reffer to that this kind off attack also can include files on the attacked server.--Henke37 22:42, 28 October 2007 (UTC)

not very neutral article

I agree with Henke37, this is not a purely php vulnerability the way article shows it, any language that allows unsanitized user input is vulnerable (which includes pretty much every programming language), this article needs to be cleaned up and rewritten. Jernejl (talk) 16:40, 8 October 2008 (UTC)

Archive 1