2012-04-20 52 views
1

考慮以下簡單的代碼:可以一個URI變量永遠是惡意

function loadthis ($var) 
{ 
     $id = $this->model->get_id($var); 
} 

問:可以任意惡意代碼不斷通過URI變量傳遞?

場景: www.mydomain.com/mycontroller/loadthis/dosomethingreallybadhere

額外的信息:

  • 我使用的模型活動記錄,所以我知道他們不能做SQL注入
  • 在這個例子中,我沒有使用form_validation類(我卻用它在其他地方爲我的形式)
  • 我限制我的URI字符由笨

    $config['permitted_uri_chars'] = 'a-z 0-9~%.:_\-'; 
    
+1

在什麼情況下malacious? – AlphaMale 2012-04-20 06:47:16

+0

我改進了我的問題AlphaMale - 請參閱scanario - 可以以任何方式成爲某種惡意代碼? – Laurence 2012-04-20 06:57:33

+1

圓點斜槓和波形符在目錄遍歷和本地文件包含攻擊中很有用。冒號有助於構建將用戶重定向到任意網站或遠程文件包含攻擊的攻擊。百分號字符在注入sql where子句時很有用。還有更多的例子。來自用戶的任何數據都可以是蘋果的,無論是在URL,Cookie,POST數據,HTTP頭還是其他任何地方。 – Cheekysoft 2012-04-20 09:42:36

回答

1

提供沒有太多你可以允許的字符做默認的...主要是你正在試圖阻止任何人是MySQL的注入或者可能是惡意腳本進入您的網站。總有一種可能性,但我認爲你對自己的產品相當安全。您要過濾的主要內容是:

  1. 行情,單引號和半冒號,因爲這些可以用於MySQL注入攻擊。
  2. HTML標記字符,如<或>,因爲這些可用於注入惡意腳本。

這絕不是結束所有列表。這些是你應該留意的主要事情。我強烈建議您閱讀https://www.owasp.org/index.php/Main_Page的安全最佳實踐

0

是和否。

「數據」本身並不危險,它只是數據。這取決於你對它做了什麼,如果數據中包含你不曾預料到的東西,這可能會產生不必要的後果。因此,對於通過URL收到的數據,或者從某處收到的任何數據,用戶可以控制,您無法知道或保證數據包含的內容。因此,不要編寫使用這些數據的代碼,並且如果數據中包含您未預料到的內容,它們將會破壞或打開安全漏洞。

如果您將其作爲外來對象並對其進行相應處理,則具有未知內容的數據並不危險。它危險,如果你把它當作你知道它在裏面什麼,即使你不知道。是的,這是一個令人費解的答案。 ;)

0

當然,這取決於代碼。如果不分析所有的代碼庫,你永遠不能說「這是完全安全的」。您的受限制的URL字符集似乎是合理的(如果它足夠用於您的應用程序)。不過,我可以想象至少有一個例子,如果用戶在URL中輸入\..\..\,在某些情況下可能會打開一個自定義文件(在Windows上),但輸入可能是惡意的。

如果你只關注SQL注入,如果你有這樣的代碼:

SELECT * FROM articles WHERE article_id = $id 

惡意用戶可以$ ID設置爲0 or 1 like 1其通過將受限制的字符集。

同樣可以做到對XSS,如果你的地方忘記正確逃生(經常發生在生成的JavaScript代碼),但例如是很難想象的。

無論如何,有沒有真正的/完美/安全限制用戶輸入來獲得安全的方式。避免XSS/SQL /不管注入的唯一辦法,是要經過所有的代碼,並確保您隨時隨地無論是輸入或輸出一些變量使用,它是正確根據使用的情況下逃脫了。規則是不限制輸入,但要做好準備,可以包含任何東西

如果輸入的是,準備一個字符串可以包含任何字符,並處理它。將它保存到數據庫中,因爲它是,並確保在保存時它不能做任何傷害。如果您在構建SQL查詢時需要轉義它,請將其轉義。如果您需要將字符串(或其一部分)放入HTML輸出中,請將其正確轉義。當然,你需要非常小心,確保你在所有地方進行適當的轉義。

+0

我的codebase是Codeigniter PHP框架。它已經防止SQL注入 - 所以我並不擔心 - 只是想知道上面的場景是否是'安全的' – Laurence 2012-04-20 07:16:46

+0

正如我所說的,除非您檢查整個代碼庫,否則不能說它是否安全。你的方法似乎是合理的,可能是一個好的開始,但其他地方總會有錯誤。你的方案似乎沒問題,但它是否「安全」取決於你對變量的確切做法。 – kuba 2012-04-20 07:54:31

相關問題