看板 PHP 關於我們 聯絡資訊
※ 引述《red0whale (red whale)》之銘言: : 如題, : 我知道能用HTTP_REFERER來判斷上一頁表單是否為從本站發送的 : 但其實這樣並不是最好的 : 因為使用者一樣能用cURL來提交一個假的HTTP_REFERER來騙過PHP : 所以有沒有一個最好的方法來判斷表單是否為從本站發送的? 如果你追求的是「完全的要求表單由本站發送」,這種東西本質上是不可能的。 因為 HTTP 本身是 stateless,資訊是在「主機」和「瀏覽器端」互相來回傳遞, 每一個 request / response 都只是「包含了資訊的單向傳遞」。 你什麼時後有了「表單是從本站發送」的幻覺? XD 表單永遠都是從你的 borwser 送出的,那是你的電腦 / 瀏覽器, 和哪個網站一點關係都沒有。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.226.146.72 ※ 文章網址: https://www.ptt.cc/bbs/PHP/M.1477489662.A.F7E.html
yanli2: 原文刪掉了 應該是原原PO找到了解決方案 10/28 16:13
tkdmaf: 也有可能是惱羞成怒所以刪了。 10/28 16:37
imhaha: 因為這篇也沒解決到問題 他生氣了XD 10/28 16:49
rockmanalpha: 比較簡單的做法就是產生一個token放在session內 10/28 18:07
rockmanalpha: 頁面塞一個input field塞那個token一起提交 到後端 10/28 18:08
rockmanalpha: 跟session比對 不過這也無法完全防止偽裝 10/28 18:09
tkdmaf: 我覺得大家都不用再提了……反正都被說成答非所問了。 10/28 18:48
GALINE: 我是覺得也不用說成這種程度...畢竟這是個滿大的需要 10/28 18:52
GALINE: 只是它真的沒有銀子彈可以解... 10/28 18:53
xxxzzz: 看到HTTP_REFERER了,還能回這篇內容,也真令人匪夷所思 10/29 00:24
spfy: 其實原原PO自我風格很強烈阿...不是他要的都不是解答 10/29 11:56
xdraculax: 為何有 HTTP_REFERER 就不能回這篇? 10/29 12:34
Peruheru: 因為那就表示已經知道請求跟伺服器無關了 10/29 13:06
Peruheru: 或是反過來說,就是不知道HTTP_REFERER的意義才會提問 10/29 13:08
Peruheru: 知道那東西能用,卻不知道那東西代表得意義 10/29 13:08
Peruheru: 我猜啦 10/29 13:09
tkdmaf: 我只能說,沒看過最原始po文的人的內容,就別瞎猜了。 10/29 13:27
tkdmaf: 總之他那句不要「答非所問」,才是最讓人感冒的。 10/29 13:27
tkdmaf: 其他你們想過的方法,那篇的推文都有提到過。 10/29 13:28
tkdmaf: 而且我最不爽的,就是問題解就刪問題的人。(不管有沒解) 10/29 13:29
tkdmaf: 如果最後要刪問題,不如一開始就別問。 10/29 13:29
tkdmaf: 刪問題這一點,我倒希望版主納入考慮一下。 10/29 13:30
Peruheru: 我看過阿,我還有推到文,應該可以猜一下XD 10/29 21:44
kyleJ: 原原PO知道HTTP_REFERER 卻不知道HTTP怎麼運作的… 10/30 11:11
fashionjack: 他們沒經過網頁就直接丟進MySQL,網頁要如何防? 10/31 08:12
fashionjack: input filed加隱藏參數我用過,識別碼用過,皆無效。 10/31 08:15
rickysu: 這些問題得透過各種不同的方式來處理 11/01 09:04
rickysu: 單純避免被Cross Site透過Referer以及Origin就可以阻擋 11/01 09:05
rickysu: 如果要阻擋使用Curl直接送出請求,那就得透過 CSRF token 11/01 09:06
rickysu: 或是 Captcha 11/01 09:07
rickysu: 如果想要避免對方短時間送出大量請求,除了 Captcha 11/01 09:07
rickysu: 還可以使用工作量證明,藉由讓Client耗費大量資源,避免 11/01 09:09
rickysu: 被灌爆,讓對方知道他要攻擊你得付出比你更多的代價。 11/01 09:09