2013-10-05 26 views
0

作爲思想實驗的一部分,我試圖確定服務器是否有希望提供一段僅用於瀏覽器環境的接收和使用的數據,即無法通過爬行我的站點的bot讀取。顯然,如果這些信息是在源代碼中發送的,或者通過任何常用的HTTP方式發送的,那麼這可以通過一個bot來獲取 - 迄今爲止,這麼簡單。傳輸僅供瀏覽器環境接收的信息?

但是,如果信息是由服務器發送的,而不是作爲websocket消息傳遞的:那麼這隻能由瀏覽器環境中的一些相應的(可能是經過身份驗證的)JavaScript接收,從而阻止了它被bot攔截? (這是基於我的假設,一個殭屍程序沒有客戶端環境,本質上是一個惡意的服務器端腳本,通過類似cURL的東西來調用網站,假裝成一個用戶)。

另一種表述這個問題的方式可能是:在websockets的web實現中,是否收到始終由客戶端環境(即JS)完成的消息?

回答

1

我無法回答關於websockets的問題,但充分動機的攻擊者會找到一種方法來模擬您所需的任何環境。通過ajax加載這些內容,你可以消除偶然的機器人。您可以使用robots.txt消除行爲良好的機器人。

+0

是的,我意識到一個承諾的攻擊將模擬任何你可以設計的環境。我能想到的唯一例外是網絡套接字,因此是個問題。 +1,但。 – Utkanos

1

使用WebSocket沒有區別。您無法逃避以下事實:您可以始終編寫一個非瀏覽器客戶端,該瀏覽器客戶端的外觀和行爲與任何標準瀏覽器完全相同。

我可以假裝:你可能會讀取任何HTTP頭(如瀏覽器供應商等)。 origin標題也沒有幫助(我可以僞造它)。餅乾也沒有。我會讀它們並將其還給你。

您可能會通過強大的驗證碼保護您的網站,並在captcha解決後才設置cookie。這取決於驗證碼是無法通過機器人解決..

+0

當然可以 - 完全同意。我的問題歸結爲,我從來沒有見過或聽說過任何服務器(即一個機器人)可以接收websocket消息的手段。事實上,只有在客戶端的實時環境中,收到websocket消息纔有意義。 +1都一樣。 – Utkanos

+0

是的,WebSocket不僅用於HTML5 /瀏覽器客戶端,還用於非瀏覽器客戶端。這具有相同的後端能夠驅動HTML5前端以及其他前端(例如原生移動應用程序)的良好效果。 – oberstet