安全性-HTML注入的所有可能原因

Question

Someone somehow managed to place an iframe to a pay per view site on my homepage. In my mind, this could only happen through FTP or SSH so I want to place an IP lock on all of the accounts.

However, I contacted my host and they said typically it's a coding vulnerability not an FTP hack.

What are the possible causes for someone to inject HTML into my index.php file?

Edit: File uploading is a part of my site. Could they have done some sort of buffer attack and made my site interpret a file as PHP commands?

Answer 1

This is not “HTML injection” as that term is normally used. That normally refers to vulnerabilities where a web application writes user input in an HTML template without escaping characters like < to < . (In PHP, this is a common problem caused by forgetting to call htmlspecialchars() in the output template, and the language not doing it automatically for you.)

However if someone has changed the contents of an existing .php file on the server you have a much worse compromise than a simple HTML injection XSS. To be able to write to the file, the attacker must have either gained access to your administative account, or exploited a file-write vulnerability in the web app and the app is running as a user that has write access to its own .php files. (Usually you should run a web app as a low-privilege user with no permission to write to app files. But in some sad shared hosting scenarios, one user may be all you get for everything.)

Regardless of what your host said, the number one cause of this kind of compromise today is, by far, FTP credential loss. The usual pattern is that a machine that is used to access the FTP server has been infected with password-stealing malware, typically as a result of visiting an infected page on another web site (which itself is often hacked).

So definitely virus checkers on all machines that have access the FTP server; use multiple AVs, and do an OS reinstall on any infected machines you find, as AVs are bad at detection and worse at removal. Then change the password of the account and stop using unencrypted FTP for god's sake it's 2013. If your host refuse to provide SFTP access then this along with the poor advice above would be good reason to dump them.

File uploading is a part of my site. Could they have done some sort of buffer attack and made my site interpret a file as PHP commands?

It's conceivable; file upload is a very difficult function to get right in general. If the web site is running as a user that has write access to any location from which your web server will run .php files, then any file-write vuln escalates to an execute-abitrary-code vuln. So audit what bits of the filesystem have write access for the web server user, and lock it down as much as possible, in addition to performing strong whitelist validation on any variables used for filenames in your app. (Best: never use any client-supplied data to form a filename.)