使用PDO選擇查詢的安全性？

我目前正在將所有舊的PHP代碼轉換爲使用PDO。我想知道什麼時候需要爲我的querys使用準備功能？

我目前有這個查詢。

$sql = "SELECT deckName FROM decks WHERE deleted = '0' ORDER by deckName";

這不是動態的，也許是刪除的列。我正在使用下面的內容重申屏幕上的數據。

foreach($DBH->query($sql) as $row){ echo $row['deckName']?> }

我仍然應該使用這個作爲良好的做法，或者是上述不夠好嗎？

$sth = $DBH->prepare("SELECT deckName FROM decks WHERE deleted = '0' ORDER by deckName");

我不太清楚如何正確使用fetch語句重複從行中的數據？提前:) 海莉

來源

2016-06-14 HybridHaylee

[如果查詢中沒有變量，可以使用PDO :: query（）方法。]（https://phpdelusions.net/pdo#query） –

當你需要綁定時使用prepare查詢中的用戶數據，否則您可以參考第一個示例。 –

我會檢查你的鏈接你的常識。看起來像一個很好的資源。 – HybridHaylee

如果常量字符串發送到數據庫，並就從來沒有在「不受信任的輸入」混合

由於安全問題是在我的經驗無關，只是一個潛在的性能方面仍然存在，這取決於底層數據庫。如果爲執行階段（在此準備，綁定= NOOP這裏，執行）第一個之後的所有調用，可以省去昂貴的解析查詢的準備步驟。

因此，從標籤猜測，你使用mysql，不要使用memcached或類似的中間層，你可能只是想測量性能，否則你可以遷移到直接查詢。當「項目」稍後需要查詢的變量參數化（基於不受信任的輸入，例如來自網絡）時，應該再次使用prepare，以防止注入攻擊。也許可以很好地找出「如何正確使用讀取聲明，當重複從行的數據」...

修改爲答覆，以適應在評論的查詢中使用變量「uppercased nevers」：

有一個實際的原因，我寫「接收不可信的輸入」，而不是「從來沒有這樣做，從來沒有」。根據我的經驗，當涉及到變量時，會出現一個滑坡：在上面的問題中，如果不審計$ sql變量的更廣泛的上下文 - 即使整個查詢對於注入攻擊來說都是潛在的無用功。另外，從常量構建查詢字符串的內部重構可能會導致混合更多變量，以組成一個充當查詢的（更復雜的）字符串。

更加平衡/間隙最小化硬化我建議：

在代碼文檔化說「信任邊界」的一個特定的地圖實現一個應用程序，並此基礎上，實施的任何嚴格的驗證跨越這些邊界的投入 - 即傳遞價值的變量 - 在大多數情況下是有效和高效的。
添加分層安全性/關注點分離的常識概念，自然會導致在「輸入」（跨越邊界）「注入」參數時使用預準備語句。

我不願意伸手，簡單的食譜給人安全的感覺樂觀，當一個與像應用程序棧這樣的scyscraper涉及基於DB Web應用程序通常會做。

來源

2016-06-14 10:17:20 Dilettant

您建議測試哪些性能問題？一次又一次重複相同的常量查詢的性能？我可以告訴你，沒有任何測試，你必須只運行這個查詢一次，因此沒有什麼可以測試的。 –

說到參數化，談論「不可信的投入」只是一個嚴重的錯覺。一個人不應該沉思數據來源，而是無條件地使用參數。 –

那麼，它可能是簡單的查詢，爲公衆編輯，或者便於閱讀，只有OP知道，然後很高興知道，人們可以衡量，並決定無論如何，持續時間/延遲總是容易解釋 - 安全，避免差距 - 並非如此。而不受信任的輸入就是它的全部內容。如果它不在那裏，好的，但容易忘記，當允許變量後面的過程中.. – Dilettant

使用PDO選擇查詢的安全性？

回答

相關問題