2015-05-11 98 views
2

我已經運行了一些獲取用戶提供的字符串的node.js代碼,調用JSON.stringify(str)並將值直接注入到SQL語句中。JSON.stringify字符串防止(My)SQL注入嗎?

例如

var x = JSON.stringify(UNSAFE_USER_STRING); 
mysql_execute('UPDATE foo SET v = ' + x + ' WHERE id = 1'); 

顯然這是JSON.stringify的濫用,但是這不是我的代碼,作者希望看到攻擊媒介,他們修補它之前。由於UNSAFE_USER_STRING是一個字符串,而不是一個對象,並沒有逃避明顯"\不是很明顯,如果有一個嚴重的問題

這段代碼安全嗎?如果不是,有人可以證明什麼是不安全的輸入?

謝謝!用這樣的評語

+0

[防止Node.js中的SQL注入](http://stackoverflow.com/questions/15778572/preventing-sql-injection-in-node-js)。使用預準備的語句 – Devon

+2

以上評論請至少在評論前閱讀問題標題。如果您閱讀完整的問題,可以獲得獎勵。 – danneu

+1

如果你不發送UTF8編碼會怎麼樣? http://stackoverflow.com/questions/12456762/accented-characters-breaks-json-encode-in-php(雖然,PHP的問題。*應該不同於node.js?*) –

回答

-1

即使被轉義,如「字符的字符(組合) - 或#仍可能導致WHERE被忽略條款

1

如果你確定x是一個字符串,然後我。 99%的人確信,這使得不可能進行SQL注入攻擊,當你不確定x的類型時,我的信心下降到90%,也就是說,考慮到以下所有情況都不應構成漏洞:

  • Null,NaN,Infinity,-Infinity似乎都回歸爲null,這是安全的。
  • 未定義回到未定義的值,而不是一個字符串,所以我不確定這一點。我認爲這會被認爲是無效的SQL,而不是構成漏洞。
  • node.js中的日期JSON.stringify(new Date())返回'「2015-11-09T18:53:46.198Z」'這正是你想要的。
  • 儘管智能轉換可以成功使用SQL數組,但數組和對象應該導致無效的SQL。也就是說,可能有一些棘手的方法來填充可能導致漏洞的對象,但我對此表示懷疑。
  • 十六進制似乎只是將其轉換爲整數。
  • 緩衝區和Uint8Arrays似乎回來作爲對象。再說一遍,可能有某種方式來填充Object,並且會有一些漏洞,但我對此表示懷疑。