SQL-инъекции.
SQL-инъекции.
Внедрение SQL-кода (англ. SQL injection) - один из самых распространенныхспособов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода. При правильной настройке системы управления базами данных вероятность успешной реализации SQL-инъекций можно свести к нулю. Но обо всем по порядку. Начнем с описания угрозы.
Внедрение SQL в зависимости от типа используемой СУБД и условий внедрения может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.
Атака типа внедрения SQL может быть возможна из-за некорректной обработки входных данных, используемых в SQL-запросах.
Разработчик прикладных программ, работающих с базами данных, должен знать о таких уязвимостях и принимать меры противодействия внедрению SQL.
Допустим, серверное ПО, получив входной параметр id, использует его для создания SQL-запроса. Рассмотрим следующий PHP-скрипт:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
Если на сервер передан параметр id, равный 5 (например, так: http://example.org/script.php?id=5), то выполнится следующий SQL-запрос:
SELECT * FROM news WHERE id_news = 5
Но если злоумышленник передаст в качестве параметра id строку -1 OR 1=1 (например, так: http://example.org/script.php?id=-1+OR+1=1), то выполнится запрос:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Таким образом, изменение входных параметров путем добавления в них конструкций языка SQL вызывает изменение в логике выполнения SQL-запроса (в данном примере вместо новости с заданным идентификатором будут выбраны все имеющиеся в базе новости, поскольку выражение 1=1 всегда истинно).
Защита от атак типа внедрение SQL-кода.
В этом посте в качестве примеров будут приводиться фрагменты исходного кода на различных языках программирования, взятые из открытого источника.
Для защиты от данного типа атак необходимо тщательно фильтровать входные параметры, значения которых будут использованы для построения SQL-запроса.
Предположим, что код, генерирующий запрос, выглядит так:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
Чтобы внедрение кода было невозможно, для некоторых СУБД, в том числе для MySQL, требуется брать в кавычки все строковые параметры. В само́м параметре заменяют кавычки на \», апостроф на \', обратную косую черту на \\ (это называется «экранировать спецсимволы»). Это можно делать таким кодом:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ на входе – строка; на выходе – строка в кавычках и с замененными спецсимволами }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
Для PHP фильтрация может быть такой:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Фильтрация целочисленных параметров.
Возьмем другой запрос:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
В данном случае поле id имеет числовой тип и его нельзя брать в кавычки. Поэтому «закавычивание» и замена спецсимволов на escape-последовательности не проходит. В таком случае помогает проверка типа; если переменная id не является числом, запрос вообще не должен выполняться.
Например, на Delphi для противодействия таким инъекциям помогает код:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
В случае ошибки функция StrToInt вызовет исключение EConvertError, и в его обработчике можно будет вывести сообщение об ошибке. Двойное преобразование обеспечивает корректную реакцию на числа в формате $132AB (шестнадцатеричная система счисления). На стандартном Паскале, не умеющем обрабатывать исключения, код несколько сложнее.
Для PHP этот метод будет выглядеть так:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Усечение входных параметров.
Для внесения изменений в логику выполнения SQL-запроса требуется внедрение достаточно длинных строк. Так, минимальная длина внедряемой строки в вышеприведенных примерах составляет 8 символов («1 OR 1=1»). Если максимальная длина корректного значения параметра невелика, то одним из методов защиты может быть максимальное усечение значений входных параметров.
Например, если известно, что поле id в вышеприведенных примерах может принимать значения не более 9999, можно «отрезать лишние» символы, оставив не более четырех:
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Петухов Олег, юрист в области международного права и защиты персональных данных, специалист в области информационной безопасности, защиты информации и персональных данных.
Телеграм-канал: https://t.me/zashchitainformacii
Группа в Телеграм: https://t.me/zashchitainformacii1
Сайт: https://legascom.ru
Электронная почта: online@legascom.ru
#защитаинформации #информационнаябезопасность
SQL injection.
SQL injection is one of the most common methods of hacking websites and programs working with databases, based on the introduction of arbitrary SQL code into a query. With proper configuration of the database management system, the probability of successful implementation of SQL injections can be reduced to zero. But first things first. Let's start by describing the threat.
SQL injection, depending on the type of DBMS used and the conditions of implementation, may enable an attacker to perform an arbitrary query to the database (for example, read the contents of any tables, delete, modify, or add data), gain the ability to read and/or write local files, and execute arbitrary commands on the attacked server.
An SQL injection type attack may be possible due to incorrect processing of input data used in SQL queries.
The developer of application programs working with databases should be aware of such vulnerabilities and take measures to counteract the introduction of SQL.
Let's say the server software receives the input parameter id and uses it to create an SQL query. Consider the following PHP script:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
If the id parameter is passed to the server equal to 5 (for example, like this: http://example.org/script.php?id=5 ), then the following SQL query will be executed:
SELECT * FROM news WHERE id_news = 5
But if the attacker passes the string -1 OR 1=1 as the id parameter (for example, like this: http://example.org/script.php?id=-1+OR+1=1 ), then the request will be executed:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Thus, changing the input parameters by adding SQL language constructs to them causes a change in the logic of executing the SQL query (in this example, instead of the news with the specified identifier, all available news in the database will be selected, since the expression 1=1 is always true).
Protection against SQL injection attacks.
In this post, fragments of the source code in various programming languages taken from an open source will be given as examples.
To protect against this type of attack, it is necessary to carefully filter the input parameters, the values of which will be used to build an SQL query.
Let's assume that the code generating the query looks like this:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
To make code injection impossible, some databases, including MySQL, require putting all string parameters in quotation marks. In the parameter itself, replace the quotation marks with \", the apostrophe with \', and the backslash with \\ (this is called "escape special characters"). This can be done with the following code:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ the input is a string; the output is a string in quotation marks and with replaced special characters }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
Для PHP фильтрация может быть такой:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Filtering of integer parameters.
Let's take another query:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
In this case, the id field has a numeric type and cannot be enclosed in quotation marks. Therefore, "quoting" and replacing special characters with escape sequences does not work. In this case, type checking helps; if the id variable is not a number, the query should not be executed at all.
For example, in Delphi, the code helps to counteract such injections.:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
In case of an error, the StrToInt function will raise an EConvertError exception, and an error message can be displayed in its handler. The double conversion ensures a correct response to numbers in the $132AB format (hexadecimal number system). On standard Pascal, which does not know how to handle exceptions, the code is somewhat more complicated.
For PHP, this method will look like this:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Truncation of input parameters.
To make changes to the logic of executing an SQL query, it requires the introduction of sufficiently long strings. So, the minimum length of the embedded string in the above examples is 8 characters ("1 OR 1=1"). If the maximum length of the correct parameter value is small, then one of the protection methods may be the maximum truncation of the input parameter values.
For example, if it is known that the id field in the above examples can take values of no more than 9999, you can "cut off the extra" characters, leaving no more than four:
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.
Telegram channel: https://t.me/protectioninformation
Telegram Group: https://t.me/informationprotection1
Website: https://legascom.ru
Email: online@legascom.ru
#informationprotection #informationsecurity
SQL-Injektionen.
SQL-Implementierung (engl. SQL injection) ist eine der häufigsten Methoden zum Hacken von Websites und Programmen, die mit Datenbanken arbeiten, basierend auf der Implementierung von willkürlichem SQL-Code in eine Abfrage. Wenn das Datenbankmanagementsystem richtig konfiguriert ist, kann die Wahrscheinlichkeit einer erfolgreichen Implementierung von SQL-Injektionen auf Null reduziert werden. Aber es geht um alles in Ordnung. Beginnen wir mit der Beschreibung der Bedrohung.
Die Implementierung von SQL kann dem Angreifer je nach verwendetem DBMS-Typ und den Implementierungsbedingungen die Möglichkeit geben, eine beliebige Datenbankabfrage durchzuführen (z. B. den Inhalt beliebiger Tabellen lesen, Daten löschen, ändern oder hinzufügen), lokale Dateien zu lesen und/oder zu schreiben und beliebige Befehle auf dem angegriffenen Server auszuführen.
Ein SQL-Einbettungstyp-Angriff kann aufgrund einer fehlerhaften Verarbeitung der in SQL-Abfragen verwendeten Eingaben möglich sein.
Anwendungsentwickler, die mit Datenbanken arbeiten, sollten sich dieser Sicherheitslücken bewusst sein und Maßnahmen ergreifen, um der SQL-Implementierung entgegenzuwirken.
Angenommen, die Serversoftware verwendet den Eingabeparameter id, um eine SQL-Abfrage zu erstellen. Betrachten Sie das folgende PHP-Skript:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
Wenn der ID-Parameter 5 an den Server übergeben wird (zum Beispiel: http://example.org/script.php?id=5 ), dann wird die folgende SQL-Abfrage ausgeführt:
SELECT * FROM news WHERE id_news = 5
Aber wenn ein Angreifer die Zeichenfolge -1 OR 1=1 als id-Parameter übergibt (zum Beispiel: http://example.org/script.php?id=-1+OR+1=1 ), dann wird die Abfrage ausgeführt:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Das Ändern der Eingabeparameter durch Hinzufügen von SQL-Konstrukten bewirkt daher, dass die Logik der SQL-Abfrage geändert wird (in diesem Beispiel werden alle Nachrichten, die in der Datenbank vorhanden sind, anstelle von Nachrichten mit der angegebenen ID ausgewählt, da der Ausdruck 1=1 immer wahr ist).
Schutz vor Angriffen wie SQL-Einbettung.
In diesem Beitrag werden Quellcodeausschnitte in verschiedenen Programmiersprachen, die aus Open Source stammen, als Beispiele aufgeführt.
Um sich vor dieser Art von Angriffen zu schützen, müssen Sie die Eingabeparameter, deren Werte zum Erstellen der SQL-Abfrage verwendet werden, sorgfältig filtern.
Angenommen, der Code, der die Abfrage generiert, sieht folgendermaßen aus:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
Für einige DBMS, einschließlich MySQL, ist es erforderlich, alle Zeichenfolgenparameter in Anführungszeichen zu setzen, damit der Code nicht eingebettet werden kann. Ersetzen Sie die Anführungszeichen im Parameter selbst durch \», den Apostroph durch \', den umgekehrten Schrägstrich durch \\ (dies wird als «Sonderzeichen maskieren» bezeichnet). Dies kann mit folgendem Code erfolgen:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ am Eingang eine Zeichenfolge; am Ausgang eine Zeichenfolge in Anführungszeichen und mit ersetzten Sonderzeichen }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
Für PHP kann die Filterung so sein:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Filtert ganzzahlige Parameter.
Nehmen wir eine andere Anfrage:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
In diesem Fall ist das ID-Feld numerisch und kann nicht in Anführungszeichen gesetzt werden. Daher funktioniert das »Zitieren" und Ersetzen von Sonderzeichen durch Escape-Sequenzen nicht. In diesem Fall hilft die Typüberprüfung; Wenn die id-Variable keine Zahl ist, sollte die Abfrage überhaupt nicht ausgeführt werden.
Zum Beispiel hilft Code auf Delphi, um solchen Injektionen entgegenzuwirken:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
Bei einem Fehler löst die Funktion StrToInt eine EConvertError-Ausnahme aus, und Sie können eine Fehlermeldung in ihrem Handler ausgeben. Die doppelte Konvertierung ermöglicht eine korrekte Reaktion auf Zahlen im Format $132AB (Hexadezimal). Bei einem Standard-Pascal, der nicht in der Lage ist, Ausnahmen zu behandeln, ist der Code etwas komplizierter.
Für PHP würde diese Methode so aussehen:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Усечение входных параметров.
Um Änderungen an der Ausführungslogik einer SQL-Abfrage vorzunehmen, müssen ausreichend lange Zeilen eingefügt werden. So beträgt die Mindestlänge der eingebetteten Zeichenfolge in den obigen Beispielen 8 Zeichen («1 OR 1=1»). Wenn die maximale Länge des gültigen Parameterwerts nicht groß ist, kann eine der Schutzmethoden darin bestehen, die Werte der Eingabeparameter maximal zu kürzen.
Wenn Sie beispielsweise wissen, dass das ID-Feld in den obigen Beispielen maximal 9999 Werte annehmen kann, können Sie die zusätzlichen Zeichen «abschneiden», wobei maximal vier Zeichen übrig bleiben:
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Oleg Petukhov, Rechtsanwalt im Bereich des Völkerrechts und des Schutzes personenbezogener Daten, Spezialist für Informationstechnik sicherheit, Schutz von Informationen und persönlichen Daten.
Telegramm-Kanal: https://t.me/datenschutzmit
Die Gruppe im Telegramm: https://t.me/datenschutzmit1
Website: https://legascom.ru
E-Mail: online@legascom.ru
#informationssicherheit #informationssicherheit
Injection SQL.
L'implémentation du code SQL (ENG. SQL injection) - l'un des moyens les plus courants de piratage des sites et des programmes travaillant avec des bases de données, basé sur l'injection de code SQL arbitraire dans la requête. Si le système de gestion de base de données est correctement configuré, la probabilité de réussite de l'injection SQL peut être réduite à zéro. Mais à propos de tout dans l'ordre. Commençons par décrire la menace.
L'injection SQL, en fonction du type de SGBD utilisé et des conditions d'injection, peut permettre à l'attaquant d'effectuer une requête arbitraire sur la base de données (par exemple, lire le contenu de n'importe quelle table, supprimer, modifier ou ajouter des données), de lire et/ou d'écrire des fichiers locaux et d'exécuter des commandes arbitraires sur le serveur attaqué.
Une attaque de type d'injection SQL peut être possible en raison du traitement incorrect des entrées utilisées dans les requêtes SQL.
Le développeur d'applications de base de données doit être conscient de ces vulnérabilités et prendre des mesures pour contrer l'implémentation de SQL.
Par exemple, le LOGICIEL serveur, après avoir reçu le paramètre d'entrée id, l'utilise pour créer une requête SQL. Considérez le script PHP suivant:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
Si le paramètre id est 5 (par exemple: http://example.org/script.php?id=5 la requête SQL suivante est exécutée:
SELECT * FROM news WHERE id_news = 5
Mais si l'attaquant passe la chaîne -1 OR 1=1 comme paramètre id (comme ceci: http://example.org/script.php?id=-1+OR+1=1), la requête est exécutée:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Par conséquent, la modification des paramètres d'entrée en y ajoutant des constructions SQL entraîne une modification de la logique d'exécution de la requête SQL (dans cet exemple, toutes les nouvelles de la base de données seront sélectionnées au lieu de l'ID spécifié, car l'expression 1=1 est toujours vraie).
Protection contre les attaques par injection SQL.
Dans cet article, des extraits de code source dans divers langages de programmation provenant de l'Open source seront fournis à titre d'exemples.
Pour vous protéger contre ce type d'attaque, vous devez filtrer soigneusement les paramètres d'entrée dont les valeurs seront utilisées pour générer la requête SQL.
Supposons que le code qui génère la requête ressemble à ceci:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
Pour que le code ne puisse pas être implémenté, certains SGBD, y compris MySQL, doivent mettre entre guillemets tous les paramètres de chaîne. Dans le paramètre lui-même, remplacez les guillemets par\», l'apostrophe par\', la barre oblique inverse par \\ (c'est ce qu'on appelle «échapper les caractères spéciaux»). Cela peut être fait avec ce code:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ en entrée – une chaîne; en sortie, une chaîne entre guillemets et avec des caractères spéciaux remplacés }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
Pour PHP, le filtrage peut être comme ceci:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Filtrage des paramètres entiers.
Prenons une autre requête:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
Dans ce cas, le champ id est de type numérique et ne peut pas être placé entre guillemets. Par conséquent, la» citation " et le remplacement des caractères spéciaux par des séquences d'échappement ne passent pas. Dans ce cas, la vérification de type aide; si la variable id n'est pas un nombre, la requête ne doit pas être exécutée du tout.
Par exemple, sur Delphi, le code aide à contrer de telles injections:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
En cas d'erreur, StrToInt lève une exception EConvertError et vous pouvez afficher un message d'erreur dans son gestionnaire. La double conversion fournit une réponse correcte aux nombres au format $132ab (hexadécimal). Sur un Pascal standard qui ne sait pas gérer les exceptions, le code est un peu plus compliqué.
Pour PHP, cette méthode ressemblerait à ceci:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Tronquer les paramètres d'entrée.
Les modifications apportées à la logique d'exécution d'une requête SQL nécessitent l'incorporation de chaînes suffisamment longues. Ainsi, la longueur minimale de la chaîne incorporée dans les exemples ci-dessus est de 8 caractères («1 OR 1=1»). Si la longueur maximale d'une valeur de paramètre valide est faible, une méthode de protection peut être la troncature maximale des valeurs de paramètre en entrée.
Par exemple, si vous savez que le champ id dans les exemples ci-dessus peut prendre des valeurs ne dépassant pas 9999, vous pouvez «couper» les caractères supplémentaires en ne laissant pas plus de quatre:
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Petukhov Oleg, avocat en droit international et protection des données personnelles, spécialiste de l'information sécurité, protection de l'information et des données personnelles.
Telegram Channel: https://t.me/protecciondelainformacion
Groupe au Télégramme: https://t.me/securiteinformatique2
Site: https://legascom.ru
E-mail: online@legascom.ru
#sécuritéinformations #informationsécurité
Injection SQL.
L'injection SQL est l'une des méthodes les plus courantes de piratage de sites Web et d'applications de bases de données. Elle consiste à insérer du code SQL arbitraire dans les requêtes. Avec un système de gestion de bases de données (SGBD) correctement configuré, la probabilité de succès d'une injection SQL peut être réduite à zéro. Mais commençons par décrire cette menace.
Selon le type de SGBD utilisé et les conditions d'attaque, l'injection SQL peut permettre à un attaquant d'exécuter des requêtes arbitraires sur la base de données (par exemple, lire le contenu de n'importe quelle table, supprimer, modifier ou ajouter des données), de lire et/ou d'écrire des fichiers locaux, et d'exécuter des commandes arbitraires sur le serveur cible.
Une attaque par injection SQL peut être rendue possible par une mauvaise gestion des données d'entrée utilisées dans les requêtes SQL.
Un développeur d'applications de bases de données doit être conscient de ces vulnérabilités et prendre des mesures pour contrer l'injection SQL..
Supposons que le logiciel serveur reçoive le paramètre d'entrée « id » et l'utilise pour créer une requête SQL. Prenons l'exemple du script PHP suivant:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
Si le paramètre id transmis au serveur est égal à 5 (par exemple, comme ceci : http://example.org/script.php?id=5), la requête SQL suivante sera exécutée:
SELECT * FROM news WHERE id_news = 5
Mais si un attaquant passe la chaîne « -1 OU 1=1 » comme paramètre id (par exemple, comme ceci : http://example.org/script.php?id=-1+OR+1=1), la requête suivante sera exécutée:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Ainsi, modifier les paramètres d'entrée en y ajoutant des constructions du langage SQL modifie la logique de la requête SQL (dans cet exemple, au lieu de sélectionner un article avec un ID donné, tous les articles de la base de données seront sélectionnés, puisque l'expression 1=1 est toujours vraie).
Protection contre les attaques par injection SQL.
Cet article utilise des fragments de code source provenant de sources ouvertes, écrits dans différents langages de programmation, comme exemples.
Pour se protéger contre ce type d'attaque, il faut filtrer soigneusement les paramètres d'entrée dont les valeurs serviront à construire la requête SQL.
Supposons que le code générant la requête ressemble à ceci:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
Pour empêcher les injections de code, certains SGBD, dont MySQL, exigent que tous les paramètres de type chaîne soient placés entre guillemets. À l'intérieur du paramètre, les guillemets sont remplacés par \", les apostrophes par \' et les barres obliques inverses par \\ (on parle alors d'« échappement des caractères spéciaux »). Ceci peut être réalisé avec le code suivant:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ L'entrée est une chaîne de caractères ; la sortie est une chaîne de caractères entre guillemets dont les caractères spéciaux ont été remplacés }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
En PHP, le filtrage peut ressembler à ceci:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Filtrage des paramètres entiers.
Prenons une autre requête:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
Dans ce cas, le champ `id` est de type numérique et ne peut pas être encadré par des guillemets. Par conséquent, l'utilisation de guillemets et le remplacement des caractères spéciaux par des séquences d'échappement ne fonctionneront pas. Dans ce cas, la vérification des types est utile ; si la variable `id` n'est pas un nombre, la requête ne doit pas être exécutée.
Par exemple, dans Delphi, le code suivant permet d'empêcher de telles injections:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
En cas d'erreur, la fonction StrToInt lèvera une exception EConvertError et un message d'erreur pourra être affiché dans son gestionnaire. La double conversion assure une gestion correcte des nombres au format $132AB (hexadécimal). En Pascal standard, qui ne gère pas les exceptions, le code est un peu plus complexe.
En PHP, cette méthode se présenterait comme suit:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Tronquer les paramètres d'entrée.
Modifier la logique d'exécution d'une requête SQL nécessite l'injection de chaînes de caractères relativement longues. Par exemple, la longueur minimale de la chaîne injectée dans les exemples ci-dessus est de 8 caractères (« 1 OR 1=1 »). Si la longueur maximale d'une valeur de paramètre valide est petite, une méthode de sécurité consiste à tronquer autant que possible les valeurs des paramètres d'entrée.
Par exemple, si l'on sait que le champ « id » dans les exemples ci-dessus ne peut accepter que des valeurs inférieures à 9999, on peut supprimer les caractères superflus, en ne conservant pas plus de quatre caractères.
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Petukhov Oleg, avocat en droit international et protection des renseignements personnels, spécialiste de l'information sécurité, protection de l'information et des données personnelles.
Canal Telegram: https://t.me/protecciondelainformacion
Groupe au Télégramme: https://t.me/securiteinformatique2
Site: https://legascom.ru
Courriel: online@legascom.ru
#sécuritéinformations #informationsécurité
Inyección SQL.
Introducción de código SQL (en Inglés). La inyección de SQL es una de las formas más comunes de hackear sitios web y programas que trabajan con bases de datos, basada en la inyección de código SQL arbitrario en una consulta. Si configura correctamente su sistema de administración de bases de datos, puede reducir a cero la probabilidad de que las inyecciones SQL se implementen correctamente. Pero todo en orden. Comencemos describiendo la amenaza.
La inyección de SQL, dependiendo del tipo de base de datos utilizada y las condiciones de implementación, puede permitir al atacante realizar una consulta arbitraria a la base de datos (por ejemplo, Leer el contenido de cualquier tabla, eliminar, modificar o agregar datos), Leer y/o escribir archivos locales y ejecutar comandos arbitrarios en el servidor atacado.
Un ataque de tipo de inyección SQL puede ser posible debido a un manejo incorrecto de los datos de entrada utilizados en las consultas SQL.
El desarrollador de aplicaciones que trabajan con bases de datos debe ser consciente de tales vulnerabilidades y tomar medidas para contrarrestar la implementación de SQL.
Digamos que el software del servidor, después de recibir el parámetro de entrada id, lo usa para crear una consulta SQL. Considere el siguiente script PHP:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
Si se pasa un parámetro id de 5 al servidor (por ejemplo: http://example.org/script.php?id=5), se ejecutará la siguiente consulta SQL:
SELECT * FROM news WHERE id_news = 5
Pero si el atacante pasa la cadena -1 OR 1=1 COMO parámetro de id (por ejemplo, así: http://example.org/script.php?id=-1+OR+1=1), se ejecutará la consulta:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Por lo tanto, cambiar los parámetros de entrada agregando construcciones del lenguaje SQL a ellos causa un cambio en la lógica de ejecución de la consulta SQL (en este ejemplo, en lugar de noticias con un id dado, se seleccionarán todas las noticias existentes en la base de datos, ya que la expresión 1=1 siempre es verdadera).
Protección contra ataques de tipo inyección de código SQL.
Esta publicación incluirá fragmentos de código fuente en varios lenguajes de programación tomados de código abierto como ejemplos.
Para protegerse contra este tipo de ataque, debe filtrar cuidadosamente los parámetros de entrada cuyos valores se utilizarán para construir la consulta SQL.
Supongamos que el código que genera la consulta se ve así:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
Para que la implementación de código no sea posible, algunos DBMS, incluido MySQL, requieren que todos los parámetros de cadena estén entre comillas. En el parámetro en sí, las comillas se reemplazan por\", el apóstrofo por\', la barra invertida por \\ (esto se llama"escapar caracteres especiales"). Esto se puede hacer con este código:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ en la entrada-una cadena; en la salida-una cadena entre comillas y con caracteres especiales reemplazados }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
Para PHP, el filtrado puede ser así:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Filtrado de parámetros enteros.
Tomemos otra solicitud:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
En este caso, el campo id es de tipo numérico y no se puede poner entre comillas. Por lo tanto, la "cita" y la sustitución de caracteres especiales por secuencias de escape no pasan. En tal caso, la verificación de tipo ayuda; si la variable id no es un número, la consulta no debe ejecutarse en absoluto.
Por ejemplo, en Delphi, el código ayuda a contrarrestar tales inyecciones:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
En caso de error, la función StrToInt generará una excepción EConvertError y podrá Mostrar un mensaje de error en su controlador. La doble conversión proporciona una respuesta correcta a los números en el formato $132AB (sistema de numeración hexadecimal). En un Pascal estándar que no puede manejar excepciones, el código es algo más complicado.
Para PHP, este método se vería así:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Truncamiento de parámetros de entrada.
Para realizar cambios en la lógica de ejecución de una consulta SQL, es necesario implementar cadenas suficientemente largas. Por lo tanto, la longitud mínima de la cadena incrustada en los ejemplos anteriores es de 8 caracteres ("1 OR 1=1"). Si la longitud máxima de un valor de parámetro válido es pequeña, un método de protección puede ser el truncamiento máximo de los valores de los parámetros de entrada.
Por ejemplo, si sabe que el campo id en los ejemplos anteriores puede tener un valor máximo de 9999, puede "cortar el exceso" de caracteres, dejando un máximo de cuatro:
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Oleg Petukhov, abogado en el campo del derecho internacional y la protección de datos personales, especialista en información seguridad, protección de la información y datos personales.
Canal de Telegram: https://t.me/protecciondelainformacion1
Grupo de Telegramas: https://t.me/protecciondelainformacion2
Sitio web: https://legascom.ru
Correo electrónico: online@legascom.ru
#proteccióndelainformación #seguridaddelainformación
Injeção SQL.
Introdução ao SQL code (em inglês). SQL injection) - um dos métodos mais comuns de hackear sites e programas que trabalham com bancos de dados, com base na introdução de um código SQL arbitrário na consulta. Se o sistema de gerenciamento de banco de dados estiver configurado corretamente, a probabilidade de implementação bem-sucedida de injeções SQL pode ser reduzida a zero. Mas tudo em ordem. Comecemos pela descrição da ameaça.
Dependendo do tipo de banco de dados usado e das condições de implementação, a injeção de SQL pode permitir que um invasor execute consultas arbitrárias ao banco de dados (por exemplo, ler o conteúdo de qualquer tabela, excluir, modificar ou adicionar dados), ler e/ou gravar arquivos locais e executar comandos arbitrários no servidor atacado.
Um ataque de injeção SQL pode ser possível devido ao processamento incorreto de entradas usadas em consultas SQL.
O desenvolvedor de aplicativos que trabalham com bancos de dados deve estar ciente dessas vulnerabilidades e tomar medidas contra a implementação do SQL.
Suponha que o software do servidor, depois de receber o parâmetro de entrada id, O Use para criar uma consulta SQL. Considere o seguinte script PHP:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
Se um id de 5 for enviado para o servidor (por exemplo: http://example.org/script.php?id=5 a seguinte consulta SQL será realizada:
SELECT * FROM news WHERE id_news = 5
Mas se o invasor passar a string -1 OR 1=1 como parâmetro de id (por exemplo: http://example.org/script.php?id=-1+OR+1=1 () o pedido será atendido:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Assim, alterar os parâmetros de entrada adicionando construções de linguagem SQL a eles causa uma alteração na lógica de execução da consulta SQL (neste exemplo, todas as notícias no banco de dados serão selecionadas em vez de notícias com o ID especificado, já que a expressão 1=1 é sempre verdadeira).
Proteção contra ataques de injeção de SQL.
Este post fornecerá exemplos de partes do código-fonte em várias linguagens de programação derivadas do código aberto.
Para se proteger contra esse tipo de ataque, é necessário filtrar cuidadosamente os parâmetros de entrada, cujos valores serão usados para construir a consulta SQL.
Suponha que o código que gera a solicitação se pareça com isso:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
Para impedir a incorporação de código, alguns bancos de dados, incluindo o MySQL, exigem aspas em todos os parâmetros de cadeia de caracteres. No próprio parâmetro, as aspas são substituídas por\", o apóstrofo por \', a barra invertida por \\ (isso é chamado de "proteger caracteres especiais"). Isso pode ser feito com esse código.:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ na entrada – string; na saída-string entre aspas e com caracteres especiais substituídos }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
Para PHP, a filtragem pode ser:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Filtragem de parâmetros inteiros.
Faça outro pedido:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
Neste caso, o campo id tem um tipo numérico e não pode ser colocado entre aspas. Portanto, a" citação " e a substituição de caracteres especiais por uma sequência de escape não funcionam. Nesse caso, a verificação de tipo ajuda; se a variável id não for um número, a consulta não deve ser executada.
Por exemplo, no Delphi, o código ajuda a combater essas injeções:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
No caso de um erro, A função StrToInt acionará uma exceção Econverter e uma mensagem de erro poderá ser exibida em seu manipulador. A conversão dupla garante a resposta correta aos números no formato $132ab (sistema de numeração hexadecimal). No Pascal padrão, que não pode lidar com exceções, o código é um pouco mais complicado.
Para o PHP, este método será assim:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Усечение входных параметров.
Para fazer alterações na lógica de execução da consulta SQL, é necessária a implementação de linhas suficientemente longas. Por exemplo, o comprimento mínimo de uma string incorporada nos exemplos acima é de 8 caracteres ("1 OR 1=1"). Se o comprimento máximo do valor correto do parâmetro for pequeno, um dos métodos de proteção pode ser o truncamento máximo dos valores dos parâmetros de entrada.
Por exemplo, se você souber que o campo id nos exemplos acima pode ter um valor máximo de 9999, poderá" cortar " caracteres extras deixando um máximo de quatro:
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Petukhov Oleg, advogado de Direito Internacional e proteção de dados pessoais, especialista em informação segurança, proteção de informações e dados pessoais.
Canal do Telegram: https://t.me/protecaodaInformacao
Grupo em Telegram: https://t.me/protecaodaInformacao1
Site: https://legascom.ru
Correio eletrónico: online@legascom.ru
#segurançadaInformação #Segurançadainformação
SQL injection.
A injeção de SQL é um dos métodos mais comuns de hackear sites e programas que trabalham com bancos de dados, com base na introdução de código SQL arbitrário em uma consulta. Com a configuração adequada do sistema de gerenciamento de banco de dados, a probabilidade de implementação bem-sucedida de injeções de SQL pode ser reduzida a zero. Mas as primeiras coisas primeiro. Vamos começar descrevendo a ameaça.
A injeção de SQL, dependendo do tipo de SGBD usado e das condições de implementação, pode permitir que um invasor execute uma consulta arbitrária ao banco de dados (por exemplo, leia o conteúdo de qualquer tabela, exclua, modifique ou adicione dados), obtenha a capacidade de ler e/ou gravar arquivos locais e execute comandos arbitrários no servidor atacado.
Um ataque do tipo SQL injection pode ser possível devido ao processamento incorreto de dados de entrada usados em consultas SQL.
O desenvolvedor de programas aplicativos que trabalham com bancos de dados deve estar ciente de tais vulnerabilidades e tomar medidas para neutralizar a introdução do SQL.
Digamos que o software do servidor receba o ID do parâmetro de entrada e o use para criar uma consulta SQL. Considere o seguinte script PHP:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
Se o parâmetro id for passado para o servidor igual a 5 (por exemplo, assim: http://example.org/script.php?id=5 ), então a seguinte consulta SQL será executada:
SELECT * FROM news WHERE id_news = 5
Mas se o atacante passar a string -1 ou 1=1 como parâmetro de id (por exemplo, assim: http://example.org/script.php?id=-1+OR+1=1 ), então a solicitação será executada:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Assim, alterar os parâmetros de entrada adicionando construções de linguagem SQL a eles causa uma alteração na lógica de execução da consulta SQL (neste exemplo, em vez das notícias com o identificador especificado, todas as notícias disponíveis no banco de dados serão selecionadas, pois a expressão 1=1 é sempre verdadeira).
Proteção contra ataques de SQL injection.
Neste post, fragmentos do código-fonte em várias linguagens de programação retirados de um código aberto serão dados como exemplos.
Para se proteger contra esse tipo de ataque, é necessário filtrar cuidadosamente os parâmetros de entrada, cujos valores serão usados para construir uma consulta SQL.
Vamos supor que o código que gera a consulta fique assim:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
Para tornar impossível a injeção de código, alguns bancos de dados, incluindo o MySQL, exigem colocar todos os parâmetros de string entre aspas. No próprio parâmetro, substitua as aspas por\", o apóstrofo por \ 'e a barra invertida por \\ (isso é chamado de"caracteres especiais de escape"). Isso pode ser feito com o seguinte código:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ a entrada é uma string; a saída é uma string entre aspas e com caracteres especiais substituídos }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
Para PHP, a filtragem pode ser assim:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Filtragem de parâmetros inteiros.
Vamos fazer outra consulta:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
Nesse caso, o campo id tem um tipo numérico e não pode ser colocado entre aspas. Portanto, "citar" e substituir caracteres especiais por sequências de escape não funciona. Nesse caso, a verificação de tipo ajuda; se a variável id não for um número, a consulta não deve ser executada.
Por exemplo, no Delphi, o código ajuda a neutralizar essas injeções.:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
Em caso de erro, a função StrToInt gerará uma exceção EConvertError e uma mensagem de erro poderá ser exibida em seu manipulador. A dupla conversão garante uma resposta correta aos números no formato $132ab (hexadecimal number system). No Pascal padrão, que não sabe lidar com exceções, o código é um pouco mais complicado.
Para PHP, este método ficará assim:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Truncamento dos parâmetros de entrada.
Para fazer alterações na lógica de execução de uma consulta SQL, ela requer a introdução de strings suficientemente longas. Portanto, o comprimento mínimo da string incorporada nos exemplos acima é de 8 caracteres ("1 ou 1=1"). Se o comprimento máximo do valor do parâmetro correto for pequeno, um dos métodos de proteção poderá ser o truncamento máximo dos valores do parâmetro de entrada.
Por exemplo, se for sabido que o campo id nos exemplos acima pode assumir valores não superiores a 9999, você pode "cortar os caracteres extras", deixando no máximo quatro:
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Petukhov Oleg, advogado de Direito Internacional e proteção de dados pessoais, especialista em informação segurança, proteção de informações e dados pessoais.
Canal do Telegram: https://t.me/protecaodaInformacao
Grupo em Telegram: https://t.me/protecaodaInformacao1
Site: https://legascom.ru
Correio eletrónico: online@legascom.ru
#segurançadaInformação #Segurançadainformação
Iniezione SQL.
Iniezione di codice SQL (inglese: SQL Injection) SQL injection è uno dei metodi più comuni per hackerare siti e programmi che lavorano con database, basato sull'iniezione di codice SQL arbitrario nella query. Con una corretta configurazione del sistema di gestione del database, la probabilità di un'implementazione SQL Injection riuscita può essere ridotta a zero. Ma prima di tutto. Iniziamo descrivendo la minaccia.
SQL Injection, a seconda del tipo di DBMS utilizzato e delle condizioni di iniezione, può consentire all'attaccante di eseguire una query arbitraria sul database (ad esempio, leggere il contenuto di qualsiasi tabella, eliminare, modificare o aggiungere dati), ottenere la capacità di leggere e/o scrivere file locali ed eseguire comandi arbitrari sul server attaccato.
Un attacco di tipo SQL Injection potrebbe essere possibile a causa di un'elaborazione errata degli input utilizzati nelle query SQL.
Lo sviluppatore di programmi applicativi basati su database deve essere a conoscenza di tali vulnerabilità e adottare misure per contrastare L'iniezione SQL.
Supponiamo che il software server, dopo aver ricevuto il parametro di input id, lo utilizzi per creare una query SQL. Considera il seguente script PHP:
…
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news = $id");
…
Se al server viene passato un parametro id pari a 5 (in questo modo: http://example.org/script.php?id=5), quindi verrà eseguita la seguente query SQL:
SELECT * FROM news WHERE id_news = 5
Ma se l'attaccante passa la stringa -1 OR 1=1 come parametro id (in questo modo: http://example.org/script.php?id=-1+OR+1=1), quindi verrà eseguita la query:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Pertanto, la modifica dei parametri di input mediante l'aggiunta di costrutti SQL in essi provoca un cambiamento nella logica di esecuzione della query SQL (in questo esempio, tutte le notizie disponibili nel database verranno selezionate anziché le notizie con un determinato ID, poiché l'espressione 1=1 è sempre vera).
Protezione contro attacchi di tipo SQL Injection.
Questo post fornirà frammenti di codice sorgente in vari linguaggi di programmazione presi dall'open source come esempi.
Per proteggersi da questo tipo di attacco, è necessario filtrare attentamente i parametri di input i cui valori verranno utilizzati per creare la query SQL.
Supponiamo che il codice che genera la query assomigli a questo:
statement := 'SELECT * FROM users WHERE name = "' + userName + '";';
Per rendere impossibile l'iniezione di codice, alcuni DBMS, incluso MySQL, richiedono di citare tutti i parametri della stringa. Nel parametro stesso, sostituire le virgolette con\", l'apostrofo con\', la barra rovesciata con \ \ (questo è chiamato «escape caratteri speciali»). Questo può essere fatto in questo codice:
statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';
function QuoteParam(s : string) : string;
{ l'input è una stringa; l'output è una stringa tra virgolette e con caratteri speciali sostituiti }
var
i : integer;
Dest : string;
begin
Dest := '"';
for i:=1 to length(s) do
case s[i] of
'''' : Dest := Dest + '\''';
'"' : Dest := Dest + '\"';
'\' : Dest := Dest + '\\';
else Dest := Dest + s[i];
end;
QuoteParam := Dest + '"';
end;
Per PHP, il filtraggio potrebbe essere così:
<?
$query = "SELECT * FROM users WHERE user='".mysql_real_escape_string($user)."';";
?>
Filtraggio dei parametri interi.
Prendiamo un'altra query:
statement := 'SELECT * FROM users WHERE id = ' + id + ';';
In questo caso, il campo id è di tipo numerico e non può essere citato. Pertanto «la "citazione" e la sostituzione dei caratteri speciali con sequenze di escape non passano. In tal caso, il controllo del tipo aiuta; se la variabile id non è un numero, la query non dovrebbe essere eseguita affatto.
Ad esempio, su Delphi, il codice aiuta a contrastare tali iniezioni:
id_int := StrToInt(id);
statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';
In caso di errore, la funzione StrToInt genererà Un'eccezione EConvertError e sarà possibile visualizzare un messaggio di errore nel relativo gestore. La doppia conversione fornisce una risposta corretta ai numeri nel formato $132ab (sistema numerico esadecimale). Su Pascal standard, che non è in grado di gestire le eccezioni, il codice è un po ' più complicato.
Per PHP, questo metodo sarebbe simile a questo:
$query = 'SELECT * FROM users WHERE id = ' . (int) $id;
Troncamento dei parametri di input.
Per apportare modifiche alla logica di esecuzione di una query SQL, è necessario implementare stringhe sufficientemente lunghe. Pertanto, la lunghezza minima della stringa incorporata negli esempi precedenti è di 8 caratteri (»1 OR 1=1"). Se la lunghezza massima del valore corretto del parametro è piccola, un metodo di protezione potrebbe essere quello di troncare al massimo i valori dei parametri di input.
Ad esempio, se si sa che il campo id negli esempi precedenti può assumere un valore massimo di 9999, è possibile «tagliare» i caratteri extra lasciando al massimo quattro:
statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';
Oleg Petukhov, avvocato nel campo del diritto internazionale e della protezione dei dati personali, specialista nel campo dell'informazione sicurezza, protezione delle informazioni e dei dati personali.
Canale Telegram: https://t.me/protezionedelleinformazioni
Gruppo in telegramma: https://t.me/protezionedelleinformazioni1
Sito: https://legascom.ru
E-mail: online@legascom.ru
#protezionedelleInformazioni #sicurezzadelleinformazioni
