Атака чрез SQL инжектиране, Microsoft Docs

Атаката с инжектиране на SQL е атака, която вмъква зловреден код в низове, които след това се предават на екземпляр на SQL Server за анализ и изпълнение. Всяка процедура, която генерира SQL изрази, трябва да се счита за опасна уязвимост при инжектиране на код, тъй като SQL Server изпълнява всички синтактично правилни заявки, които получава. Дори параметризираните данни могат да бъдат манипулирани от опитен нападател.

Основната форма на SQL Injection атака е директното инжектиране на код във въведени от потребителя променливи, които се комбинират със SQL команди и се изпълняват. По-малко очевидна атака инжектира опасен код в низове, предназначени да бъдат съхранени в таблица или като метаданни. Когато съхранените редове впоследствие се обединят с динамична SQL команда, се изпълнява опасен код.

Следният скрипт показва проста атака чрез SQL инжектиране. Скриптът генерира SQL заявка чрез свързване на твърдо кодирани низове с низ, въведен от потребителя:

Потребителят е подканен да въведе името на града. Ако потребителят въведе в Redmond, тогава скриптовата заявка изглежда по следния начин:

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

Да предположим обаче, че потребителят въвежда следното:

Редмънд'; пуснете таблица OrdersTable--

В този случай заявката, създадена от скрипта, ще бъде следната:

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

Ако вмъкнатият SQL код е синтактично правилен, неправилно формираните данни не могат да бъдат открити програмно. Поради това е необходимо да се проверява коректността на всички данни, въведени от потребителите, както и внимателно да се преглеждаткод, който изпълнява генерирани от SQL команди на сървъра. Препоръчителните практики за програмиране са описани в следващите подраздели на този раздел.

Валидиране на всички входни данни

Винаги потвърждавайте всички въведени от потребителя данни, като проверявате типа, дължината, формата и диапазона на данните. Когато прилагате предпазни мерки срещу злонамерено въвеждане, вземете под внимание архитектурата и сценариите за внедряване на приложението. Имайте предвид, че програмите, предназначени да работят в защитена среда, могат да бъдат копирани в незащитена среда. Препоръчва се следната стратегия:

Не правете никакви предположения относно размера, вида или съдържанието на данните, които вашето приложение получава. Например, препоръчва се да се оцени следното.

Как ще се държи приложението, ако потребител погрешка или злонамерено вмъкне 10 MB MPEG файл, където приложението очаква да бъде въведен пощенски код?

Как ще се държи приложението, ако оператор DROP TABLE бъде инжектиран в текстово поле?

Проверете размера и типа на входните данни и задайте подходящи ограничения. Това ще помогне за предотвратяване на умишлено препълване на буфера.

Когато работите с XML документи, проверете всички въведени данни спрямо схемата.

Никога не създавайте Transact-SQL изрази директно от потребителски вход.

Използвайте съхранени процедури за валидиране на въведеното от потребителя.

В многослойни среди всички данни трябва да бъдат валидирани, преди да бъдат предадени към доверената зона. Данните, които не преминават процеса на валидиране, трябва да бъдат отхвърлени и грешката да бъде върната на предишното ниво.

Внедрете многоетапно валидиране. Взети предпазни мерки срещу случайни злонамерени потребители,могат да бъдат неефективни срещу организаторите на умишлени атаки. Препоръчва се валидиране на данните, въведени през потребителския интерфейс, и след това във всички следващи точки на преминаване на границите на доверената зона.

Например валидирането на данни в клиентско приложение може да предотврати просто инжектиране на скрипт. Въпреки това, ако следващото ниво предполага, че входните данни вече са проверени, тогава всеки нападател, който успее да заобиколи клиентската система, ще може да получи неограничен достъп до системата.

Никога не обединявайте въведени от потребителя данни без валидиране. Конкатенацията на низове е основната входна точка за инжектиране на скрипт.

Не позволявайте следните низове в полетата, от които могат да се генерират имена на файлове: AUX, CLOCK$, COM1-COM8, CON, CONFIG$, LPT1-LPT8, NUL и PRN.

Когато е възможно, отхвърляйте въвеждане, съдържащо следните знаци:

---