題:
可以秘密執行GET請求嗎?
Kargari
2018-06-19 09:57:36 UTC
view on stackexchange narkive permalink

說,我的服務器上有一個我想保密的頁面或文件夾。

  example.com/fdsafdsafdsfdsfdsafdrewrewrew.html  

  example.com/fdsafdsafdsfdsfdsafdrewrewaa34532543432/admin/index.html 

如果路徑的秘密部分很長,我可以假設擁有這樣一個秘密頁面或區域是安全的,並且很難猜測或強行使用它嗎?

這種方法通常有什麼問題?

請注意,我並不是在問如何正確執行此操作,但是如果有的話,這種方法可能會帶來什麼問題。

如果您的機器是安全的(https,良好的wifi等),並且您從未公開鏈接到該秘密URL,那麼外人很難猜測一個長的靜態URL。
哦,您已經關閉了建議路徑的目錄列表和“智能錯誤”頁面...
請注意,某些成熟的Web服務(例如Google Docs(具有按鏈接共享功能)和Overleaf(協作的在線Latex編輯器)等公認的Web服務認為這種做法“足夠好”。
@FedericoPoloni: Google可能會跟踪批量請求並最終阻止它們。沒有適當的設置,通過暴力破解(相對於URL的長度)很可能成功。
某些網站會這樣做,例如用於密碼重置鏈接。如果您決定走這條路,最安全的選擇就是將機密設為GET參數(即index.html?secret = hjasdhasdhasdasd),以避免緩存和機械手意外絆倒您的鏈接,並將其設為“臨時”
密碼重置鏈接中的@BgrWorker令牌應僅使用一次,然後丟棄。OP要求的是可以重用的固定值,而不是 完全一樣的東西
只要該路徑從未公開過,就很難猜測,但是這是通過隱蔽性實現的安全性,因此URL並沒有真正的安全性。我的建議是將其擴展一點,並使url哈希動態化,因此所有index.html都將被命中,它將在不同但已知的路徑上進行,在某些框架中比其他框架更容易實現。
如果是通過https進行的,那還不如傳遞密碼或也可用於其他目的的密碼那麼糟糕。
@FedericoPoloni Google Docs是否不允許將訪問限制為某些帳戶,所以其他人即使猜測了URL也無法訪問?並且Overleaf V2默認情況下保持鏈接共享關閉。
@GoodDeeds鏈接共享是Google文檔允許的共享選項之一。您還可以決定共享到特定帳戶,但這是另一回事。
從本質上講,這基本上是安全性,而僅憑它本身是遠遠不夠的。
@CompuChip不,不是。密碼就是“默默無聞的安全”,因為不是每個人都知道密碼。
@DrEval也許我當時誤解了這個問題,但是我讀到的是OP只是想通過使URL難以猜測而不是適當地保護它來掩蓋該頁面,例如使用密碼。
@CompuChip如果URL足夠安全,它將“成為”密碼。它仍然是不安全的,因為這不是傳輸密碼的好方法,但是它並不是通過隱秘來保證安全性。
如果您有一個robots.txt文檔,該文檔可以提供一些網址,但是如果它們是秘密的機會,則永遠不要將它們放在robots.txt中。
如果有人可以查看Web服務器日誌,則可以找到所有這些有趣的URL。
還與之相關:[猜測Google文檔鏈接的可能性有多低?](https://security.stackexchange.com/questions/29449/how-unlikely-is-it-that-a-google-doc-link-被猜測)
請訪問[“通過晦澀難懂的安全性是個壞主意”)(https://stackoverflow.com/questions/533965/why-is-security-through-obscurity-a-bad-idea)。
八 答案:
forest
2018-06-19 10:04:32 UTC
view on stackexchange narkive permalink

您實際上是在詢問在GET請求中傳遞秘密參數是否安全。實際上,這被歸類為漏洞。假設服務器僅在指定無效路徑時簡單地返回靜態404響應,否則強行強制使用足夠長的偽隨機字符串是不可行的,但是實踐中還有許多其他安全問題使之成為危險技術:

  • 日誌記錄軟件通常以明文形式記錄GET請求,而不以POST記錄日誌。

  • 使用GET可以使 CSRF變得不重要 * sup>處理活動內容時。

  • 引用標頭可能會將機密值洩露給其他網站。

  • 瀏覽器歷史記錄將保留在GET請求中傳遞的機密。

第二個示例中包含 / admin / 。在我看來,這意味著僅憑此路徑的知識就足以在管理員上下文中向服務器進行身份驗證。這是非常不安全,並且不應做為主要網絡安全性 faux pas /?password = hunter2 進行。

相反,機密應在POST請求中發送。如果無法執行此操作,或者您的威脅模型是排他性的以防止URL受到暴力攻擊(例如,密碼重置鏈接在使用後立即失效),那麼它應該是安全的如果做得仔細。我不知道有任何旁通道攻擊會提供一種比蠻力更快地獲取字符串的方法。

*避免參數化的GET請求不會阻止CSRF攻擊,這是常見的誤解,因為有多種方法可以類似地濫用POST(偽造表單等),但是在GET中傳遞機密確實會使CSRF更容易。 sub>

*“ [[CSRF](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF))成為問題。實際上,僅使用POST作為機密會減輕CSRF。” *如鍊接的OWASP中所述文章,這實際上並不能阻止CSRF。
我認為這確實只會在某些情況下增加難度,因為JavaScript可以跨源提交表單,而無需任何用戶交互。雖然編輯很好。
是的阻止它的唯一方法是拒絕外部引薦來源。
“從技術上講,不可能用暴力破解這樣的隨機字符串,”->為什麼不呢?
@Kargari因為服務器不會告訴您猜測字符串的距離有多近。如果輸入錯誤的字符串,則無論關閉1個字符還是關閉50個字符,它都會返回404。這樣,您將必須窮盡所有可能的字符串進行搜索,直到您正確地確定_exactly_為止。無論如何,我可能應該說“不可行”而不是“不可能”。現在進行編輯。
定時攻擊可能是可能的;我懷疑網絡服務器和操作系統在檢查路徑是否存在時會使用固定時間比較!
@dn3s我不知道對流行的HTTP服務器有任何實際的旁通道攻擊。
服務器不會告訴您猜測字符串的距離。如果輸入錯誤的字符串,則無論關閉1個字符還是關閉50個字符,它都會返回404。`->當然。那就是蠻力進來的地方
@Kargari蠻力非常非常慢。對於30個字符的字母數字字符串(即a-z,A-Z和0-9),您有62 ^ 30種可能的組合,超出了今天的範圍。
也許@dn3s意味著如果服務器逐字符進行比較,它將在第一個差異處停止,從而允許定時攻擊。但是我認為時差可能太小而無法測量。
您可以通過存儲隨機字符串的散列來減輕這種定時攻擊。因此,時間會告訴您哈希匹配的字符數,但這與原始字符串匹配的字符數無關。
對於我來說,這有點晦澀難懂,但我無法通過快速搜索找到此類示例。我現在很想知道這是否是問題(或者通常來說,可以使用定時邊通道從服務器提取什麼樣的文件系統信息)。我可能對此有疑問!
OWASP鏈接被誤解了,他們指的是信息,URL哈希不是“信息”。但是,這是通過隱秘獲得的安全。
至於引薦來源標頭,您可以阻止其發送[通過在鏈接中添加`rel =“ noreferrer”`](https://stackoverflow.com/questions/5033300/stop-link-from-sending-referrer-到目的地)。
如果曾經通過http而非https訪問過這個晦澀(不是秘密)的路徑,則該URI將是可見的,並且可能會在任何中間系統上登錄。另外,如果曾經在共享計算機上訪問過它,則可以在瀏覽器的歷史記錄中將其恢復。問這個問題是件好事,但是OP首先要問的是什麼問題,這意味著這樣做可能不是一個好主意,無論OP打算以哪種形式使用它。
這不是“魔術鏈接”的工作方式嗎?
儘管不再適用,但我認為如果您鍵入直接從惡意站點訪問該站點,ActiveX漏洞將使地址欄洩漏。
“ hunter2”通行證的來源:http://bash.org/?244321=
根據[OWASP REST安全備忘單](https://www.owasp.org/index.php/REST_Security_Cheat_Sheet#Sensitive_information_in_HTTP_requests),您不應在URL中傳遞敏感數據,但是可以在標頭中傳遞敏感數據。
那麼,Google為什麼要使用它?
Google @enkryptor不這樣做。通過GET發送搜索查詢與通過GET發送密碼不同。
誰正在談論發送密碼的@forest?OP詢問一種秘密鏈接,他說“秘密頁面”。對我來說,這既不是向他的帳戶發送密碼,也不是在其他地方獲得特權。這只是一個秘密鏈接。
@enkryptor那麼Google這樣做意味著什麼?
@forest Google的鏈接共享使您可以訪問帶有鏈接的私人文檔。鏈接本身成為該文檔的“密碼”,直到文檔所有者允許它為止
WoJ
2018-06-19 16:49:00 UTC
view on stackexchange narkive permalink

這是共享公共內容的通用方法,僅限於知道URL的人。一個示例是Google文檔:

enter image description here

第二個選項“知道鏈接的任何人”都會創建一個與您相似的鏈接。與Google相冊,Dropbox等相同...

  • 優點是內容的傳播受到了一些的限制。
  • 缺點是多少取決於您與誰共享鏈接,在何處發布等等。

您應該考慮的一件事是很容易使鏈接無效(通過更改/重新生成指向您數據的鏈接)

這也是“取消訂閱”鏈接的常用機制。
此答案引用了Google文檔,但是(正確地)提到Docs不會創建鏈接_直到所有者決定共享它_。這與創建內容的那一刻起只有一個鏈接是不同的,例如在OP的情況下。我不能強行強制任意用戶的私人文檔,只有他們故意為其建立公共鏈接的那些文檔。
我還要補充一點,就是Google對幾乎每個人(或至少每個瀏覽器;擁有或不擁有Google帳戶都沒有關係,每個擁有瀏覽器的人都擁有Google內部帳戶)具有_vast_知識,並且他們可以在後台使用它在授予或拒絕通過唯一鏈接訪問可用文檔時。問題是,OP是否有類似的數據和工具可供使用。
-1
@WoJ Google會主動跟踪瀏覽器及其用戶(Analytics,標籤管理器,API,字體,reCaptcha,8.8.8.8等在整個網絡中使用率很高),因此當您的瀏覽器通過唯一URI請求文檔時,Google已經了解更多超出您的期望(當然,跟踪唯一的Docs鏈接的生命是同一故事的一部分)。這使得挑戰甚至過濾掉犯規球員變得容易。
@Pavel:啊是的,現在我明白你的意思了。的確如此,並且用於對用戶進行指紋識別的機制(不僅是Google也是其他人)非常強大。儘管已清除了cookie,但一些受TOTP / HOTP機制(例如Google Authenticator使用的F2A)保護的站點仍可以識別傳入設備這一事實,這一事實令人印象深刻。
Artelius
2018-06-19 17:37:40 UTC
view on stackexchange narkive permalink

錯誤的主意。很多次,我都看到“秘密” URL很快就吸引了搜索引擎抓取工具的點擊,然後可以通過網絡搜索發現。我什至看到有人在其域的子文件夾中建立了一個信譽良好的網站的副本,並與一個人共享,然後他很快收到了一封電子郵件通知,警告他該域可能已被盜用釣魚目的。

這是怎麼發生的?在後一種情況下,Web瀏覽器具有內置的反網絡釣魚功能,該功能將訪問的URL發送給欺詐檢測服務。在其他情況下,也許瀏覽器正在收集瀏覽數據並將其發送到搜索引擎以收集用戶習慣。

如果您這樣做,請確保您的robots.txt(或標頭/元標記)的設置是為了告訴搜索引擎不要為內容編制索引。碰巧打噴嚏。

“引擎不會為內容建立索引。”->是否不會通過將其網址添加到robots.txt中來為我的秘密頁面建立索引?
**切勿在“ robots.txt”中放置任何機密!**確保“所有人”發現您的機密頁面的最佳方法是將其添加到“ robots.txt”中,因為這時需要發現秘密的方法是查看“ robots.txt”。
@Kargari沒有理由將實際“秘密頁面”的網址放入robots.txt中。機械手文件完全能夠禁止整個目錄層次結構。如果您的秘密位於/nocrawl/page/sdghskdfjgneowsvnoiernow.htm中,則“ Disallow:/ nocrawl”指令將適用於它。
但是我的路徑中沒有“'/ nocrawl”目錄,並且不想將其添加到我的路由中只是為了達到robtots.txt的目的!
-1
抓取者不必遵守`robots.txt`。我懷疑有些程序會做相反的事情:只檢查被“ robots.txt”“隱藏”的東西。
@Kargari“ / nocrawl”是一個示例,而不是處方。在嘗試使用robots.txt文件之前,請[閱讀](http://www.robotstxt.org/robotstxt.html)。
-1
*“網絡瀏覽器具有內置的反網絡釣魚功能,可將訪問的URL發送給欺詐檢測服務” * ...等等,這是什麼?這樣,欺詐檢測功能可以查看每一個Google文檔或您曾經“通過鏈接共享”的任何內容嗎?
iirc robots.txt語法允許您拒絕所有路徑/文件,然後專門允許路徑和文件。
有點相關:我曾經通過電子郵件向某人發送_secret_ URL,卻發現在打開電子郵件之前已訪問該URL。原來,我撰寫電子郵件時,Yahoo Mail的包括“電子郵件中的鏈接預覽”功能已對其進行了訪問。用戶代理具有一個“約...” URL,建議使用robots.txt阻止該用戶代理的頁面。
Sjoerd
2018-06-19 11:55:15 UTC
view on stackexchange narkive permalink

如果路徑的秘密部分很長,很難猜測或強行使用它嗎?

是的。攻擊者必須猜測整個事物才能發現它。由於存在很多可能性,因此將花費不可行的時間。

這種方法通常有什麼問題?

此問題是網址不是秘密的,因此會將其存儲在瀏覽器中,日誌中以及任何中間代理的形式。這樣,您的“秘密” URL可能會暴露出來。

在處理活動內容時,使用GET會使CSRF變得微不足道。

否。在CSRF攻擊中,攻擊者偽造特定請求。在URL中使用機密時,攻擊者甚至不知道偽造請求的正確URL。這意味著只要URL是秘密的,CSRF就不可能。

如果頁面上到處都是``,這不是秘密。
此外,如果最終在該名稱空間中獲得成千上萬個有效的秘密URL,那麼暴力攻擊發現SOMETHING的機會就會增加成千上萬...。
Thomas
2018-06-21 19:29:07 UTC
view on stackexchange narkive permalink

正如其他人所說,這不是一個好主意。這種用於退訂或類似一次性目的的“秘密”鏈接通常是相對短暫的,並且一旦使用一次就沒有用。

當我閱讀此問題時,我的最初想法是是該網址不會長期保密。我認為也許Chrome(或任何其他現代網絡瀏覽器)會使用地址欄中的數據來初始化抓取。 事實證明他們沒有。但是,研究人員發現插件仍然可能會觸發爬網:

結果非常簡單:Googlebot從未訪問過測試中的任何頁面。

出來,測試中的兩個人實際上並沒有禁用他們的擴展,這導致了來自Open Site Explorer(有人安裝並啟用了Mozbar)和Yandex(歸因於另一個人)的訪問,儘管我不清楚是哪個擴展他們已經安裝並啟用)。

這意味著一旦使用了鏈接,瀏覽器擴展可能會損害它。然後就不需要強行使用任何東西。

建立這些鏈接的目的是什麼? OP,您想達到什麼目標?我敢肯定還有其他到達那裡的方法...

Mr. E
2018-06-19 21:24:26 UTC
view on stackexchange narkive permalink

很難猜出/蠻力,但是其他獲取路徑的方法也是可能的

例如,URL可能會被Google,Bing等服務索引。當用戶在google中搜索您的頁面時,您的“秘密”網址就會出現。配置 robots.txt 文件可以解決該問題,但請記住,索引器可能會忽略它

應用程序中的鏈接可能會重定向到隱藏路徑

另外,與訪問“秘密”頁面或Web服務器的用戶位於同一網絡中的計算機可以看到url,還可以看到每個中間代理和用戶的ISP(如果使用VPN,則可以看到VPN)

最後,網址可能會保留在瀏覽器的緩存和/或歷史記錄以及Web服務器和代理的日誌中

**切勿在“ robots.txt”中放置任何秘密!**確保“所有人”發現您的秘密頁面的最佳方法是將其添加到“ robots.txt”中,因為這時需要發現秘密的方法是查看“ robots.txt”。
-1
您可能知道@MrE,但是閱讀您答案的人們可能不明白。
Gillian
2018-06-20 21:16:03 UTC
view on stackexchange narkive permalink

可以秘密執行GET請求嗎?

是的,可以。與沒有適當安全措施的任何類型的請求一樣。

如果路徑的秘密部分很長,我可以假定擁有這樣的秘密頁面或區域是安全的,並且

不,要擁有這樣的秘密頁面或區域並不安全。是的,很難猜測或強行使用它。

這種方法通常有什麼問題?

與POST請求不同,可以在Web瀏覽器歷史記錄中輕鬆找到GET請求。

ViDiVe
2018-06-24 23:50:51 UTC
view on stackexchange narkive permalink

我認為最好通過自動或手動方式(以便您決定誰可以訪問該頁面)通過電子郵件發送OTP一次性密碼。

在手動情況下:-您收到來自email@example.com的請求
-您授予對email@example.com的訪問權限
-腳本使用OTP創建鏈接
-鏈接將被郵寄到email @ example.com
-當用戶email@example.com訪問該頁面時,將標記OPT,並且沒有其他人可以重用該鏈接

當然,此系統需要一個數據庫來存儲授權的電子郵件,OPT和標誌字段



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...