1. 首頁
  2. 問答
  3. 包含網站邏輯的安全和JavaScript文件

包含網站邏輯的安全和JavaScript文件

2010-02-18 45 views
4

現在像jQuery這樣的JavaScript庫比以往更受歡迎，.js文件開始包含越來越多的網站邏輯。如何以及從何處獲取數據/信息，處理信息的方式等等。這不一定是壞事，但我想知道延長這可能是一個安全問題。包含網站邏輯的安全和JavaScript文件

當然，數據的真正處理仍然發生在使用PHP或其他語言的後端，並且確保在這一點上沒有不必要的事情發生是關鍵。但僅僅通過查看站點的.js（很大程度上依賴於jQuery），它會告訴一個人或許比開發人員想的還要多。特別是因爲現在的每個瀏覽器都帶有相當豐富的Web開發環境或附加組件。即使是新手操縱DOM也不是什麼大事。一旦你弄清楚了代碼的存在，以及你如何通過編輯DOM來影響它，這個'有趣'就開始了。

所以我的主要問題是：

  1. 我不希望每個人都能夠看一個.js文件，看看到底（或者說：對於很大一部分）怎麼我的網站，網頁應用程序或CMS的作品 - 有什麼，它有什麼作用，它是如何做的等等。

  2. 我很擔心通過'揭幕'這個信息，比我更聰明的人想出了一個辦法操縱DOM以影響他們現在知道該站點使用的JavaScript函數，可能會繞過我實現的後端檢查（因此錯誤地認爲它們足夠好）。

我已經爲不同的.js文件使用了不同的部分。一個Web應用程序。但總有一些東西必須在全球範圍內提供，有時候這些東西比我想公開的要多。而且因爲它都是「在那裏」，所以誰說他們無法找到其他文件。

我有時會看到一個沒有換行符和JavaScript的巨大查詢。就像緊湊的jQuery文件一樣。我確定有一些應用程序或技巧可以將常規的.js文件轉換爲一個長字符串。但是，如果它能做到這一點，是不是很容易把它變回更易讀的東西（除了節省空間之外，使它變得毫無意義）？

最後我在想是否有可能檢測到.js文件的請求是否來自網站本身（通過將腳本包含在HTML中）而不是直接下載。也許通過使用例如阻塞後者Apache的ModRewrite，可以在HTML中使用.js文件，但是當有人試圖訪問它時，它會被阻止。


您對此有何看法？我反應過度了嗎？我應該儘可能多地分割我的JS，還是花更多時間三重檢查（後端）腳本幷包括更多檢查以防止造成傷害 - 這樣做？或者是否有一些最佳做法來限制JavaScript及其包含的所有信息的曝光度？

來源

2010-02-18 Alec

回答

6

如果您設置正確，則JavaScript中的任何內容都不應構成安全風險。嘗試訪問JavaScript文件中發現的AJAX端點應檢查用戶的權限，如果它們沒有正確的權限則會失敗。

讓別人看到你的JavaScript只是一個安全風險，如果你做的事情像打電話給/ajax/secret_endpoint_that_requires_no_authentication.php這樣的事情，在這種情況下你的問題不是不安全的JavaScript，它是不安全的代碼。

我有時會看到一個沒有換行符和JavaScript的巨大查詢。就像緊湊的jQuery文件一樣。我確定有一些應用程序或技巧可以將常規的.js文件轉換爲一個長字符串。但是，如果它能做到這一點，是不是很容易把它變回更易讀的東西（除了節省空間之外，使它變得毫無意義）？

這通常是縮小（以減少帶寬使用），而不是混淆。它很容易扭轉。有混淆技術會使所有變量和函數名稱變得像「aa」，「bb」等一樣無用，但是它們可以通過足夠的努力進行反轉。

最後我在想是否可以檢測到.js文件的請求是否來自網站本身（通過將腳本包含在HTML中）而不是直接下載。也許通過使用例如阻塞後者Apache的ModRewrite，可以在HTML中使用.js文件，但是當有人試圖訪問它時，它會被阻止。

可以這樣做，但任何半主管攻擊者都可以輕鬆解決。 底線：沒有你發送非特權用戶的瀏覽器應該是有沒有是敏感數據。

來源

2010-02-18 22:59:21 ceejayoz

+0

@邁克爾·布魯克斯這些都應該在服務器端解決。用戶輸入不應在客戶端進行消毒，因爲它不受信任。 – ceejayoz 2010-02-18 23:06:24

+1

夥計，採取Xanax。 – ceejayoz 2010-02-18 23:13:23

+1

有些情況下，當用戶數據未命中服務器時需要客戶端驗證。例如，用戶通過clickTAG = javascript向敏感域上託管的易受攻擊的swf發送鏈接，以便在敏感域上竊取受害者的Cookie。這裏開發人員只能在以http（s）開頭的輸入上調用getURL。基於DOM的XSS是另一種情況，其中userinput用於說明設置innerHTML，而沒有任何客戶端清理。請注意，服務器使用的數據必須經過驗證服務器端，我們不應該依賴任何客戶端驗證。 – mar 2010-02-18 23:51:50

0

有免費的軟件JavaScript Obfuscation。雖然雖然沒有安全性，但卻很模糊。這並不能阻止對你係統的所有攻擊。它確實使其變得更加困難，但其他人無法撕掉JavaScript並使用它。

還有客戶端信任問題。通過在客戶端擁有大量的邏輯，客戶端可以選擇想要執行的內容。例如，如果您在JavaScript中轉義引號以防止SQL注入。黑客將編寫漏洞利用代碼來完全繞過逃逸例程來構建自己的HTTP請求。

TamperData和FireBug通常被黑客用來獲得對Web應用程序的更深入的理解。

僅JavaScript代碼CAN在其中存在漏洞。一個很好的例子是DOM Based XSS。雖然我承認這不是一種非常常見的XSS類型。

來源

2010-02-18 22:58:26 rook

0

那麼，你是正確的思考這個東西。這是Web應用程序開發中的一個不平凡且誤解很多的領域。

在我看來，答案是肯定的，它可以可以創建更多的安全問題，只是因爲（如你指出）的攻擊載體增加。從傳統（非JS）Web應用程序和相同的最佳實踐和方法基本上沒有太多變化將很好地服務於您。例如，注意SQL注入，緩衝區溢出，響應分割等等......你只需要更多的地方需要注意。

就腳本本身而言，圍繞跨域安全性的問題可能是最普遍的。研究並學習如何避免特別是XSS攻擊，以及CSRF攻擊。

JavaScript模糊處理通常不是出於安全原因而進行的，您說得對，它可以相當容易地進行逆向設計。人們這樣做，部分是爲了保護知識產權，但主要是爲了使代碼下載體重更小。

我推薦由O'Reilly出版的名爲'保護Ajax應用程序'的克里斯托弗韋爾斯書。

來源

2010-02-18 23:03:33

2

當然，您應該花更多時間檢查後端腳本。您必須像安全問題一樣處理安全問題，就好像攻擊者是您網站上的關鍵開發人員之一一樣，一個人確切知道一切是如何運作的。網站中的每個URL都會對數據庫執行一些操作，以確保每個參數都在允許的限制內：用戶只能更改自己的數據，只能在合法範圍內進行更改，只能更改狀態，允許更改等等等等等等。沒有任何東西與Javascript的外觀有什麼關係，或者是否有人可以閱讀它，而且jQuery與這個問題完全沒有任何關係（除非你已經完成了這一切都錯了）。

請記住：對您的網站的HTTP請求可能來自任何地方，並且可能由Universe中的任何軟件啓動。你無法控制這一點，並且沒有做任何事情來限制客戶端可以加載什麼頁面會對其產生任何影響。不要打擾「參考」檢查，因爲這些值可能是僞造的。不要依賴Javascript中的數據清理例程，因爲這些例程可以被繞過。

來源

2010-02-18 23:09:21 Pointy

相關問題

 相關問題