首頁  >  文章  >  後端開發  >  mysql_real_escape_string() 真的安全嗎?亞洲字符編碼的潛在陷阱。

mysql_real_escape_string() 真的安全嗎?亞洲字符編碼的潛在陷阱。

DDD
DDD原創
2024-10-26 15:02:02590瀏覽

 Is mysql_real_escape_string() Really Safe? The Potential Pitfall with Asian Character Encodings.

防止SQL 注入:mysql_real_escape_string() 的限制

雖然mysql_real_escape_string() 通常用於防止利用用於防止SQL 注入。聲稱可以在不使用預準備語句的網站上使用特定的亞洲字元編碼來繞過它。

繞過問題

根據 Justin Shattuck 的說法,繞過是可以透過使用 Big5 或 GBK 字元編碼中的字元來實現。這些編碼允許反斜線表示為二級或更高階字節,這可能會混淆 mysql_real_escape_string() 使其無法正確轉義它們。

Stefan Esser 的解釋

Stefan Esser 狀態該漏洞是由於mysql_real_escape_string() 不知道透過SET NAMES 所做的更改而產生的,而SET NAMES 可以切換編碼。當使用多位元組編碼時,反斜線可以表示為多個位元組,可能會繞過轉義過程。

UTF-8 安全嗎?

Esser 指出UTF-8 是此問題的例外,因為它可以正確處理任何位元組位置的反斜線。不過,他建議使用 mysql_set_charset 來更改編碼,因為它是一個更安全、更新的選項。

建議

要完全防止 SQL 注入,建議使用準備好的語句,這些語句不易受到此繞過問題的影響。如果準備好的語句不是選項,您應該考慮以下事項:

  • 避免將SET NAMES 與mysql_real_escape_string() 一起使用
  • 必要時使用mysql_set_charset 更改編碼
  • 必要時使用mysql_set_charset 更改編碼
使用UTF-8 編碼,因為它不容易受到此繞過

以上是mysql_real_escape_string() 真的安全嗎?亞洲字符編碼的潛在陷阱。的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn