在查詢中使用$ _SESSION ['id']是不是很糟糕？

當人登錄時，他得到$_SESSION['id']並且它變成了從mysql表中取得的他的id。然後我做了像SELECT * FROM members WHERE member_id = {$_SESSION['id']}這樣的mysql查詢。

那麼，安全嗎？ $ _SESSION ['id']可以消失，或者黑客可以編輯它嗎？

謝謝。

來源

2011-04-06 good_evening

如果有一個代碼路徑可能會導致此查詢在未經過設置會話變量的代碼的情況下執行，那麼「是」，變量可能會「消失」，只需強制一個新會話，然後沿着該代碼路徑。 – 2011-04-06 14:21:02

我認爲它是總是不好通過插入或連接變量來創建查詢。相反，你應該使用一個Prepared Statement，這將保證防止SQL注入類型的攻擊。恕我直言，他們也使代碼看起來更好。

來源

2011-04-06 14:13:21 Kevin

理論上，客戶端無法影響$ _SESSION數組，因爲會話數據存儲在服務器上。但是在實踐中，絕對不要相信這一點，因爲黑客可以使用另一個安全漏洞和$ _SESSION ['id']代替壞東西。

做到這一點，把ID即可查詢之前：

$_SESSION['id'] = intval($_SESSION['id']);

來源

2011-04-06 14:13:25

+1。沒有理由*不*這樣做。 – 2011-04-06 14:18:17

你的意思是intval吧？ – DShook 2011-04-06 14:19:28

什麼樣的安全漏洞？要遠程更改會話，您需要直接訪問會話存儲介質，或者在OP代碼中找到一些中間漏洞。只要不存在'$ _SESSION ['id'] = $ _GET ['hidden_s33krit_id_overrride']'，我看不到遠程惡意用戶如何更改會話變量。 – 2011-04-06 14:20:01

<?php 
$stmt = mysqli_prepare($con, "SELECT Name FROM members WHERE member_id = ? LIMIT 1"); 
mysqli_stmt_bind_param($stmt, "s", $_SESSION['id']); 
mysqli_stmt_execute($stmt); 
mysqli_stmt_bind_result($stmt, $name); 
mysqli_stmt_fetch($stmt); 
mysqli_stmt_close($stmt); 

echo 'name is '.$name; 
?>

來源

2011-04-06 14:17:05 Sourav

會話無法更改，但一些如何被黑客攻擊，如果你有Firefox和COOKIE編輯器，你可以看到PHPSESID的內容，這是存儲會話數據的文件名，如果用戶修改成功然後他攻擊他人會話！ – Sourav 2011-04-06 14:18:36

如果你喜歡mysqli_query，你可以嘗試使用mysqli_real_escape_string：P – Sourav 2011-04-06 14:22:07

黑客會猜測一個有效的會話ID，這不是一件容易的事情......除非他可以注入一些JavaScript（這被稱爲XSS）來讓一些可憐的靈魂餅乾發送給黑客。 – 2011-04-06 15:05:42

你是對的，因爲頭瓦爾都在用戶的控制就值得懷疑。

您生成一個有效的ID，但我可以通過例如將我的$ _SESSION ['id']設置爲1234 OR 1==1並且（理論上）將返回所有用戶記錄來篡改它，除非您清理該變量。

可以取用戶數據，但始終驗證它。將其設置爲臨時變量，然後運行諸如preg_replace("[^A-Za-z0-9]", "", $_SESSION['id'])之類的內容以刪除任何非字母數字字符。這還不夠，但這是向更安全的用戶輸入邁出的一步，而不是所謂的「SQL注入」。

來源

2011-04-06 14:18:41 buley

'$ _SESSION ['id']'不是標題變量？ – 2011-04-06 14:52:42

正如已經暗示的那樣，您絕不應該假定類型安全。不是因爲有人可以攻擊你，也可能是因爲你可能犯了錯誤或配置你的服務器的人。由於PHP會話可以存儲在文件系統中（默認），因此可以將它們存儲在Memcache中，也可以編寫自己的會話存儲處理程序（以db爲單位存儲會話）。假設發生了一個錯誤 - 您將會話保存到數據庫，您篡改了數據庫，並且錯誤地將值更改爲其他值，而不是整數（或浮點類型），您收到帶有逗號的字符串， - 這不符合你上面發佈的查詢 - 並且瞧，你會得到錯誤。沒有人喜歡得到錯誤和閱讀錯誤描述 - 尤其是不是你的用戶。

所以，要回答你的問題 - 信任任何人都不好。永遠不要相信外來投入，總會有不止一個失敗點 - 爲了安全，無論是_POST，_GET，_SESSION還是其他任何東西，清理您的輸入。

來源

2011-04-06 14:25:17

-1

它是總是壞到認爲。思考一些變量是否安全。
你是一名程序員。讓你編程思考這些小事，然後轉向更有趣的事情。

來源

2011-04-06 14:27:46

程序員應該始終知道變量可以包含哪些值並且不能包含哪些值。你怎麼知道程序應該對它執行什麼樣的檢查？ – 2011-04-06 14:50:58

downvote不是我的，但我不明白你的意思。你會不同意在將變量放入查詢之前在變量上做一個intval'至少是有用的嗎？ – 2011-04-06 17:37:45

是的，我願意。但我不同意上面提出的廣泛聲明。不思考導致假設，這正是導致安全錯誤的原因。做intval並且知道你爲什麼這樣做。不僅僅是通過intval無意識地運行所有的東西，然後假設世界上的所有東西都是安全的。 – 2011-04-07 10:15:15

-1

什麼是和不在$_SESSION基本上是在你的控制之下。除了使用一些諸如黑客入侵服務器和編輯臨時PHP存儲文件之類的高級內容之外，瀏覽器無法控制這一點。

幾乎每個身份驗證都依賴於SESSION數組中某些變量的設置來跟蹤當前用戶。這可以被認爲是安全的。只要你避免具體移交控制權交給瀏覽器語句，如：

$_SESSION['id'] = $_POST['id']

等。

儘管如此，其他人回答說永遠不要通過字符串連接構造數據庫查詢是有效的。總是通過mysql_real_escape_string()運行的東西是一個很好的做法，所以作爲一名優秀的程序員，您可以使用一個包裝函數/類來爲您自動執行該操作，所以您永遠不會錯誤。

來源

2011-04-06 14:58:15

在查詢中使用$ _SESSION ['id']是不是很糟糕？

回答

相關問題