緩衝區溢出SQL注入是如何發生的？

我曾經遇到過在我的滲透測試的職業生涯很多網站在其網站都有嚴格的WAF，但有時可以通過緩衝區溢出的邏輯被繞過。例如，考慮一個查詢緩衝區溢出SQL注入是如何發生的？

http://example.com/something.php?id=-1 UNION SELECT 1,2,3,4,5,6--+ 考慮易受攻擊的列是直到7。所以，現在，這應該輸出一個易受攻擊的列號作爲輸出，但它會得到錯誤。

現在，

http://example.com/something.php?id=-1 UNION%23AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%0aselect 1,2,3,4,5,6--+

這其實打印出真正的列數，這意味着它已經被忽略。我知道％23 =＃和％0A =空格。但我不明白這是幕後的行爲。我的意思是後端邏輯。

誰能給我SQL結構的一個例子可能會導致這種類型的緩衝區溢出的，考慮到後端是後端結構（數據類型）和$查詢過的條款MYSQL ..

幫助，將不勝感激

來源

2016-01-08 Yada Rahall

這聽起來更像是通過發送輸入大於旁路籤名而不是緩衝區溢出，這是一種非常具體的面向內存導向類型的條件， –

選擇* from anytablename其中id = 假設這是查詢，然後當我們嘗試Normal UNION SELECT。從某種意義上說，「易受攻擊」列的數量不是「打印」。可能有兩件事是我認爲的 1）防火牆它阻止聯盟+選擇 2）在數據庫中輸入驗證基於數據類型和更大的輸入數據庫可以打擾，因爲你告訴所以你有一個例子如何第二點可以創建，並且允許Memory @DavidHoelzer需要什麼預防措施 –

這樣做的技術解釋可能不是字面上緩衝區溢出。

對我而言，這看起來像是簡單地打敗了一個樸素的過濾器的機制......它看起來像依賴外部解決方案的症狀，如某種內容檢查防火牆或自制軟件逃脫，以掩蓋有人不知道，不關心，或者懶得編寫正確的代碼......而是試圖通過阻止髒輸入來「解決」漏洞。

這種方法往往失敗，因爲應該可以預期的。

代碼是脆弱的或不是的話，並且如果是，則應用這種「安全」的機制，而不是固定所述斷碼是相當多不可原諒。這看起來像一個海報小孩。

漏洞的解釋很簡單：%0A根本不是空格......這是一個換行符（\n）。

你如何終止在MySQL與#開始評論？如果你說「換行符」，你就贏了。

從「#」字符到行尾。

http://dev.mysql.com/doc/refman/5.7/en/comments.html

所以，這是一個單一的，有效的查詢......

SELECT ... WHERE ... UNION #AAAAAAA...\n 
SELECT ...

...和一些有關這似乎繞過任何原始過濾機制阻止其他查詢，因爲無論使用什麼手段查找可疑的UNION*SELECT都會對解析SQL做出不正確的假設。

這看起來並不像一個緩衝區溢出 - 它看起來像原始代碼展示平凡，普通，慵懶的SQL注入漏洞，「保護」的背後或由原始的過濾器增強。

來源

2016-01-08 23:22:02

緩衝區溢出SQL注入是如何發生的？

回答

相關問題