被插入額外碼的情況。大多是網站有犯了以下問題所造成的。

1.sql命令被注入的模式：
也就是你的sql資料中，有直接接受get或是post的方式運行，但並未去做資料的過濾處理。
這樣就容易發生內容被插入對應的html碼處理。常見的方式是插入iframe。

2.view樣版的作用：你的view可容許以下行為的情況下。如上傳機制變更樣板檔，sql內存樣版。
這些其實等同第1的效果。只是差別的是，因為是要做view處理的。所以你並不太能做強制判斷處理。

3.編輯器文章內容，容許使用flash上傳或是上傳html等等。

4.最後就是被知道你的ftp了。或是你的檔案系統登入太過簡單。可以讓人家進去直接修改你的系統。但大數來說，如果是這個因素的話，大多數都是會直接變動你的內容。

5.可上傳php程式碼，並可運行。這我想也不用說什麼了，只要能上傳php程式且可運行，就一定可以幹任何事了。

6.套裝系統的插件問題。

7.外來來源的js應用或程式應用。

由於並不太明白你的網站是自行開發，還是使用套件程式處理的。自行開發的話，要非常注意1 2 3點。套件系統則大多可以從其相關官方得到一些補救的機制。但編輯器的部份就要很特別小心。

第1點的處理，可以參照一些sql防注入的方式做一些基本防護。如輸入的來源可以直接確定數字型態的話。就直接宣告成數值。因為數值是最不容易注入。但如果是字串型態的話，就將一些不太可能的方式，如做html碼處理。這要看你是什麼型態處理。一般你可以自行實驗你的輸入或是登入的地方。簡易測試如下的字元「' or 1」「" or 1」。看是否能輸入通過。一但可以通過就代表你的sql一定可以被注入很大。

view上傳的處理，一般我會直接禁用 <iframe 與 <scrpit 等字元的應用處理
畢竟容許這兩個的情況下，也是可以很單純的就做插入動作處理。
不過一般我會從輸出時下手就是。

其餘的地方則需要看你的情況才能知道。會比較擔心的是主機商本身的安全性問題。
因為之前我就曾經遇過一個案例，就是我做的東西。在客戶的主機上，一段時間就一定會被改掉。
當然後期我採用了md5檔案驗証的機制，並搭配了cron每日進行檢查。

也確實抓到了檔案變更人員為root人員。(該客戶是空間用戶，不可能有root帳號)
像這樣的方式，就是只能換主機商了。