可能危險的文本輸入處理

我已經閱讀了SQL注入，XSS和其他安全問題，並試圖找出如何使用來保護公司的網站。可能危險的文本輸入處理

我們即將有一個textarea部署一個簡單的「用戶反饋」的形式，使用戶可以告訴我們如何改善網站以提高他們的用戶體驗。

當用戶在表單上按'提交'時，我們從用戶處讀取textarea註釋，然後以編程方式在該用戶的子文件夾中創建一個文件名，並將其註釋保存到文件中。然後我們將文件名和路徑添加到該用戶的數據庫記錄。

團隊並不擔心安全問題，但我是。他們的想法是「我們創建文件名，基於任何用戶輸入，它是0％，並且由於我們將這個'UserX註釋'的文件名和路徑寫入數據庫，沒有直接的用戶影響 - 所以沒有風險。」

我關注的不是數據庫活動 - 因爲他們是對的，用戶有什麼，我們寫信給他們的數據庫記錄，因爲我們剛剛創建自己的文件名並將其存儲在自己的數據庫記錄沒有任何作用。

我的問題是文本文件！

所以我上訪我們的小團隊重寫代碼使用安全textarea的文本文件讀取然後寫入用戶的評論。

我擔心的是 - 因爲我們打算實際閱讀我們用戶的反饋並打開這些文本文件以供以後閱讀 - textarea中可能有壞東西（除非我們清理它）會以某種方式傷害我們。

我堅持我們使用strip_tags（），但我需要聽取關於我們清理textarea輸入的方式的消息 - 我在想strip_tags（）是這裏的路，但我100％新的消毒用戶輸入。我查看了htmlspecialchars（），但它只是將某些字符（如'&'）轉換爲& 等等。

是否有其他方式來santize /安全做出的任何文本的用戶類型爲textarea的我們寫出來給我們的Web服務器上的文件之前？

來源

2012-03-10 wantTheBest

'htmlspecialchars'也將'<' and '>'轉換爲'<'和'>'，這足以防止顯示使用輸入的任意html。 – kirilloid 2012-03-10 03:23:08

我認爲這引發了一個問題：爲什麼你將這些存儲在文本文件而不是數據庫中？ – 2012-03-10 03:24:59

上午 - 很好的問題 - 因爲這是一個100％的新功能，我們不知道它將使用多少，所以現在我們不添加代碼和數據庫模塊來處理安全問題等，但如果在部署它變成一個不常使用的功能，然後將它存儲在數據庫中可能會更好。 – wantTheBest 2012-03-10 03:29:18

看起來像strip_tags是一個好方法。我還建議在webroot之外編寫文件，以便瀏覽器無法訪問它。另請參閱：This Other Thread

來源

2012-03-10 03:20:32 TecBrat

+1在'webroot之外' - dagnabbit是很好的建議 - 謝謝。 – wantTheBest 2012-03-10 03:49:45

只需使用mysql_real_escape_string（）來擺脫引號。 htmlentities（）如果你擔心js文件。這應該和它一樣好。

來源

2012-03-10 03:19:33

這裏有另一個添加到你的其他 - 沒有想過使用real_escape_string（） - 謝謝。 – wantTheBest 2012-03-10 03:50:38

+1 ???? @wantTheBest一般的引號出了什麼問題，以及mysql_real_escape_string（）會對他們做些什麼？ – 2012-03-10 04:31:08

清理輸入只能通過刪除某些字符來防止sql注入。但是，這些字符不能從文本文件中以惡意方式進行操作。我碰巧知道很多關於惡意軟件的信息，相信我，你在這裏沒有風險。

編輯：

如果我種種原因錯過了這個職位通過我的散漫的點，不要讓我知道這樣我就可以更新我的答案。

來源

2012-03-10 03:21:31

+1感謝一絲解脫的靈感。我想我只是想知道在創建一個文件之前知道我沒有在磁盤上寫入任何有潛在危險的東西。 – wantTheBest 2012-03-10 03:52:09

不是問題，你肯定不是。您必須將該文件保存爲可執行文件，並且STILL，執行惡意腳本所需的足夠數據的機會將很少。 – 2012-03-10 04:15:18

這取決於你如何創建一個文件，以及你在閱讀文本後對文本做什麼。

如果您使用PHP的本地函數來編寫文件，那麼您應該沒有remote code execution問題。

如果您在閱讀完所有內容後都會通過HTML htmlentities()向用戶顯示，這會使文本中的HTML標籤無法正常顯示，但仍能正確顯示給用戶，這應該足夠了。

如果您將其用作某個數據庫查詢的一部分，則應在使用該數據庫清理例程將其連接到SQL之前使用該數據庫清理例程。（即針對MySQL的mysql_real_escape_string()，或針對PostgreSQL的pg_escape_string()）。

您可能還想看看關於the OWASP page的一些信息。

編輯：我忘了提及，你還應該使用ENT_QUOTES和htmlentities來防止單引號注入。

來源

2012-03-10 03:23:56 Nathan

是的，它基本上是將textarea的'value'讀入一個javascript變量，然後使用PHP文件函數將其保存到基於文本光盤的文件中。最初，團隊中的任務是閱讀所有反饋並向我們所有人進行演示，並優先確定「必須擁有」的東西（許多用戶想要/抱怨的東西）。 – wantTheBest 2012-03-10 03:33:35

我應該說用戶在推送'提交'後看不到他們的評論 - 他們的評論只是保存到光盤文件中，並且團隊成員閱讀它們。我們的網站上沒有UI，用戶可以閱讀或編輯他們之前提交的評論。 – wantTheBest 2012-03-10 03:39:50

+1 Nathan感謝偉大的鏈接 - 特別是OWASP網站 - man這個網站的安全性是一個很大的範圍。我們現在有一些工作要處理我們的網站。 – wantTheBest 2012-03-10 03:57:11

如果您不擔心SQL注入，並且看起來不是（因爲您知道SQL已經過消毒或因爲您正在保存到文本文件中），那麼另一個問題是可能的XSS攻擊。

很容易忽略這些，它們不會直接影響你。 XSS攻擊是一種攻擊，它允許用戶將客戶端腳本注入網頁。你的數據庫工作正常，你的服務器文件沒有被修改，你的會話文件也不會被修改。

此漏洞完全是客戶端。就像我說的，它不會影響你的服務器。但是隨後有人（即：我）會進入您的網站，並突然將其重定向到Warez站點，同時查看完全SFW的可信網站。你失去了用戶的信任。抓取您網站的搜索引擎也會將您標記爲可能有害。你失去了交通。你失去了收入。然後，你的服務器再好不過了。

您肯定需要消毒是輸出回，因爲這個用戶的用戶輸入。是的，strip_tags是一個解決方案，所以htmlspecialchars或htmlentities。

strip_tags是少一點限制然而，因爲它允許你定義一些您希望用戶能夠在自己的崗位插入，像大膽，links，或斜體標籤。

總之，你絕對正確地堅持這種做法。它不會直接影響您（即：您公司的服務器），但如果您想在萬維網上獲得可信賴的存在，它會在某些時候影響您。

我知道這可能比其他誰應該建議只有strip_tags更長的答案。他們是完全正確的，這就是爲什麼我提高了他們的原因。試圖給你一些「公司」的論據。 :)

來源

2012-03-10 03:49:37 netcoder

+1那裏 - 哇客戶端腳本注入（聽起來像XSS一點）。我會閱讀它。在某些時候，當這種情況發生時，如同上面提到的幾個人一樣，項目會像任何網站一樣發展，最終這個'用戶反饋'輸入可能會在用戶提交後可以被用戶查看和編輯，並且可以保存到數據庫中 - - 客戶端腳本注入，man。「你肯定需要清理因此輸出回用戶的用戶輸入。」謝謝你的澄清。 – wantTheBest 2012-03-10 04:04:36

我有一個解決方案，遵循您的開發團隊意識形態的主流：
不要在您的網站上使用任何用戶授權，包括管理員。因此，XSS也不會傷害你。

來源

2012-03-10 04:38:06

可能危險的文本輸入處理

回答

相關問題