關於Sql注入的那些事

    登錄註冊應該是每個網站的必作的業務，可是在選擇使用Django中的ORM仍是說執行原生的Sql語句不一樣的人應該會有不一樣的建議，有經驗的開發人員都喜歡原生的sql語句，由於相對於ORM來講，執行效率高，能夠隨意地按照本身的思想去查詢本身想要的數據，還有一點，就是看上去NB一點，不服不行

    對於sql注入來講，最開始沒有一點理解，我認爲那是網絡安全應該去管理的，但最後本身莫名的攤上事了，說大白話吧，當用戶沒有註冊可是他點擊登陸的時候，提交上的用戶名以及密碼是你應該去sql語句去拼接以後去你本身的數據庫User表中去查詢看一下有沒有這個用戶名和密碼，或者說去判斷你用戶表中是否是這我的和這個密碼，ok，麻煩來了，這就是重點，就通常人而言回不會給你搗亂，可是對於一些攻擊者或者說開發來講隨意輸入，萬一用戶名輸入一個 「or 1 = 1」 ，密碼隨意或者不輸入，完蛋了，明明沒有這我的沒有這個密碼可是一看他本身登上去了

    正常的用戶登陸sql語句

　　

select * from User where name = "led" and password = 123

    惡意攻擊登陸sql語句

    

select * from User where name="or 1 = 1 #and password = 123

    解釋一下，惡意攻擊的sql語句必定會登錄上，只由於咱們在執行sql語句進行身份校驗的時候等待的是外邊用戶輸入的信息，咱們沒有對他進行一個嚴格的檢驗，而 # 這個符合在sql語句中表明註釋，不會被執行，也就是說在其真正執行的·sql語句不過就是 select * from User where name = 「or 1 = 1」 ，1=1？√，1=1 True  or這個連接詞表示兩個檢驗前面是真後邊無論是否是真都是真，So，這就是sql注入

    如今咱們知道了sql語句注入，可是咱們怎麼來避免它呢？用ORM？其實如今網上有很多各自的說法都有，有的說ORM就能夠避免這個問題，可是也有人說只要在外部輸入的信息咱們進行拼接都會有可能出現這種問題，最保險的辦法仍是說無論是使用sql仍是說ORM咱們在對於外部信息傳入咱們在拼接前咱們對其進行一個嚴格的檢驗，例如正則表達式，不符合個人規則你給我滾一邊去