1. Présentation générale
Au cours des deux dernières années, les experts en sécurité devraient accorder davantage d'attention aux attaques au niveau de la couche application réseau. Car peu importe la solidité de vos règles de pare-feu ou la diligence avec laquelle vous les appliquez, si les développeurs de vos applications Web ne respectent pas le code sécurisé, les attaquants entreront dans votre système via le port 80. Les deux principales techniques d'attaque largement utilisées sont les attaques par injection SQL [ref1] et CSS [ref2]. L'injection SQL fait référence à la technique d'insertion de métacaractères SQL (caractères spéciaux représentant certaines données) et d'instructions via la zone de saisie Internet pour manipuler l'exécution des requêtes SQL back-end. Ces attaques ciblent principalement les serveurs WEB d'autres organisations. Les attaques CSS garantissent que du code Javascript malveillant s'exécute sur la machine de la victime en insérant des balises de script dans les URL, puis en convainquant les utilisateurs qui leur font confiance de cliquer dessus. Ces attaques profitent de la relation de confiance entre l'utilisateur et le serveur. En effet, le serveur ne détecte pas les entrées et sorties, et ne rejette donc pas le code JavaScript.
Cet article traite des techniques de détection des vulnérabilités d’injection SQL et d’attaque CSS. Il y a eu de nombreuses discussions sur Internet à propos de ces deux types d'attaques basées sur le WEB, notamment sur la manière de mettre en œuvre les attaques, leur impact et la manière de mieux préparer et concevoir des programmes pour prévenir ces attaques. Cependant, il n’y a pas suffisamment de discussions sur la manière de détecter ces attaques. Nous utilisons le populaire open source IDS Snort [réf. 3] pour formuler des expressions régulières basées sur des règles de détection de ces attaques. Soit dit en passant, les paramètres de règles par défaut de Snort incluent des méthodes de détection CSS, mais celles-ci peuvent facilement être évitées. Par exemple, la plupart d'entre eux utilisent le codage hexadécimal, tel que %3C%73%63%72%69%70% 74%3E au lieu de <script> pour éviter la détection.
En fonction des capacités de l'organisation au niveau de la paranoïa, nous avons écrit plusieurs règles pour détecter la même attaque. Si vous souhaitez détecter toutes les attaques possibles par injection SQL, vous devez simplement faire attention à tous les méta-caractères SQL existants, tels que les guillemets simples, les points-virgules et les doubles tirets. Une autre façon extrême de détecter les attaques CSS consiste simplement à faire attention aux crochets angulaires dans les balises HTML. Mais cela détectera beaucoup d'erreurs. Pour éviter cela, il faut modifier les règles afin de rendre leur détection plus précise, sans pour autant éviter les erreurs.
Utilisez le mot-clé pcre (Perl Compatible Regular Expressions) [ref4] dans les règles Snort, et chaque règle peut être appliquée avec ou sans d'autres actions de règle. Ces règles peuvent également être utilisées par des logiciels publics tels que grep (un outil de recherche de documents) pour consulter les journaux du serveur réseau. Cependant, vous devez vous méfier du fait que le serveur WEB enregistrera les entrées de l'utilisateur dans le journal uniquement lorsque la demande est soumise en tant que GET. Si la demande est soumise en tant que POST, elle ne sera pas enregistrée dans le journal.
2. Expressions régulières pour l'injection SQL
Lorsque vous choisissez une expression régulière pour une attaque par injection SQL, il est important de se rappeler qu'un attaquant peut effectuer une injection SQL en soumettant un formulaire ou via le champ Cookie. Votre logique de détection des entrées doit prendre en compte différents types d'entrées organisées par l'utilisateur (telles que les informations de formulaire ou de cookie). Et si vous trouvez de nombreux avertissements provenant d'une règle, gardez un œil sur les guillemets simples ou les points-virgules, car ces caractères peuvent être des entrées valides dans les cookies créés par votre application Web. Par conséquent, vous devez évaluer chaque règle par rapport à votre application Web particulière.
Comme mentionné précédemment, une expression régulière détaillée pour détecter les attaques par injection SQL doit prêter attention aux méta-caractères spéciaux de SQL, tels que les guillemets simples (') et les signes d'expansion double (--), afin de connaître ces caractères et leur nombre d'équivalents hexadécimaux, les expressions régulières suivantes s'appliquent :
2.1 Expressions régulières pour détecter les méta-caractères SQL
/(%27)|(')|(--)|(%23)|(#)/ix
explication :
Nous vérifions d'abord l'hexagone de l'équivalent du guillemet simple, le guillemet simple lui-même ou le double signe d'expansion. Il s'agit de caractères MS SQL Server ou Oracle, indiquant que les éléments suivants sont des commentaires et que tous les suivants seront ignorés. De plus, si vous utilisez MySQL, vous devez faire attention à l'apparition de « # » et de son équivalent hexadécimal. Notez que nous n'avons pas besoin de vérifier l'équivalent hexadécimal du double tiret, car il ne s'agit pas d'un méta-caractère HTML et ne sera pas encodé par le navigateur. De plus, si un attaquant parvient à modifier manuellement le double tiret à sa valeur hexadécimale de %2D (en utilisant un proxy comme Achilles [réf. 5]), l'injection SQL échouera.
La nouvelle règle Snort ajoutée à l'expression régulière ci-dessus est la suivante :
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,established;uricontent:".pl";pcre:
"/ (%27)|(')|(--)|(%23)|(#)/i";type
de classe : attaque d'application Web ; rev : 5 ;)
cet article Dans la discussion, la valeur du mot-clé uricontent est ".pl" car dans notre environnement de test, le programme CGI est écrit en Perl. La valeur du mot-clé uricontent dépend de votre application particulière. Cette valeur peut être ".php", ou ".asp", ou ".jsp", etc. De ce point de vue, nous ne montrons pas les règles Snort correspondantes, mais nous donnerons les expressions régulières qui créent ces règles. Vous pouvez facilement créer de nombreuses règles Snort via ces expressions régulières. Dans les expressions régulières précédentes, nous avons détecté des doubles tirets car il peut y avoir des points d'injection SQL même s'il n'y a pas de guillemets simples [réf. 6]. Par exemple, une entrée de requête SQL contient uniquement des valeurs numériques, comme suit :
sélectionnez valeur1, valeur2, num_valeur3 dans la base de données
où num_value3=some_user_supplied_number
Dans ce cas, l'attaquant peut exécuter des requêtes SQL supplémentaires. La démonstration soumet l'entrée suivante :
3 ; insérer des valeurs dans some_other_table.
Enfin, les modificateurs pcre 'i' et 'x' sont utilisés pour faire correspondre la casse et. ignorer respectivement l'espace vide. Les règles ci-dessus peuvent également être étendues pour vérifier la présence de points-virgules. Cependant, le point-virgule peut très bien faire partie d'une réponse HTTP normale. Afin de réduire cette erreur et d'éviter toute apparition normale de guillemets simples et de signes d'expansion double, les règles ci-dessus doivent être modifiées pour détecter en premier la présence de signes =. L'entrée de l'utilisateur répondra à une requête GET ou POST. Généralement, l'entrée est soumise comme suit :
username=some_user_supplied_value&password=some_user_supplied_value
Par conséquent, les tentatives d'injection SQL feront apparaître l'entrée de l'utilisateur après le signe a = ou sa valeur hexadécimale équivalente.
2.2 Corrigez l'expression régulière pour détecter les méta-caractères SQL
/((%3D)|(=))[^n]*((%27)|(')|(--)|( %3B)|(:))/i
Explication :
Cette règle prête d'abord attention au signe = ou à sa valeur hexadécimale (%3D), puis considère zéro ou plusieurs caractères à l'exception des nouvelles lignes, et détecte enfin les guillemets simples et les tirets doubles ou. point-virgule.
Une injection SQL typique tentera de manipuler la requête d'origine autour de l'utilisation de guillemets simples afin d'obtenir une valeur utile. Cette attaque est généralement discutée en utilisant la chaîne 1'or'1'='1. Cependant, la détection de cette chaîne peut facilement être évitée, par exemple en utilisant 1'or2>1 --. Cependant, la seule partie constante est la valeur de. le caractère initial, suivez un guillemet simple et ajoutez « ou ». La logique booléenne qui suit peut varier selon une gamme de styles, du plus ordinaire au plus complexe. Ces attaques peuvent être détectées avec assez de précision à l'aide de l'expression régulière suivante. Le chapitre 2.3 explique.
2.3 Expression régulière typique d'une attaque par injection SQL
/w*((%27)|('))((%6F)|o|(%4F))((%72)|r| (% 52))/ix
explication :
w* - Zéro ou plusieurs caractères ou traits de soulignement.
(%27)|' - un guillemet simple ou son équivalent hexadécimal.
(%6 F)|o|(%4 F))((%72)|r|-(%52) - Le cas de 'or' et son équivalent hexadécimal.
union'Requête SQL en injection SQL les attaques sont également très courantes dans diverses bases de données. Si l'expression régulière précédente ne détecte que des guillemets simples ou d'autres métacaractères SQL, cela provoquera de nombreuses erreurs. Vous devez modifier davantage la requête pour détecter les guillemets simples et les clés « union ». également être étendu avec d'autres mots-clés SQL, comme 'select', 'insert', 'update', 'delete', etc.
2.4 Détection de l'injection SQL, expression régulière du mot-clé de requête UNION
/ ((%27)|(') )union/ix
(%27)|(') - guillemet simple et son équivalent hexadécimal
union - Le mot-clé union
peut également être utilisé pour personnaliser des expressions pour d'autres requêtes SQL, telles que >select, insert, update, delete, drop, etc.
Si, à ce stade, l'attaquant a découvert que l'application Web a une injection SQL vulnérabilité, il essaiera d’en profiter. S'il se rend compte que le serveur principal est un serveur MS SQL, il essaiera généralement d'exécuter des procédures stockées dangereuses et étendues. Ces procédures commencent généralement par les lettres « sp » ou « xp ». En règle générale, il peut essayer d'exécuter la procédure stockée étendue « xp_cmdshell » (qui exécute les commandes Windows via SQL Server). L'autorité SA du serveur SQL a l'autorité pour exécuter ces commandes. De même, ils peuvent modifier le registre via xp_regread, xp_regwrite et d'autres procédures stockées.
2.5 Explication de l'expression régulière
/exec(s|+)+(s|x)pw+/ix
pour détecter les attaques par injection SQL MS SQL Server:
exec - mot-clé qui demande l'exécution d'une procédure stockée stockée ou étendue
(s|+)+ - un ou plusieurs espaces ou leurs équivalents http
(s|x) p- Les lettres « sp » ou « xp » sont utilisées pour identifier les procédures de stockage ou de stockage étendu
w+ - un ou plusieurs caractères ou traits de soulignement correspondant au nom d'une procédure
3. Expression régulière pour les scripts intersites (CSS)
Lors du lancement d'une attaque CSS ou de la détection d'une vulnérabilité d'un site Web, un attaquant peut d'abord créer une simple balise HTML telle que < b> (gras), <i> (italique) ou <u> (souligné), ou il pourrait essayer une simple balise de script comme <script>alert("OK")</script> Parce que la plupart des publications et Ceci est. utilisé comme exemple pour détecter si un site Web présente des vulnérabilités CSS propagées via Internet. Ces tentatives peuvent être facilement détectées. Cependant, un attaquant intelligent pourrait remplacer la chaîne entière par sa valeur hexadécimale. De cette façon, la balise <script> apparaîtra sous la forme %3C%73%63%72%69%70%74%3E. D'un autre côté, un attaquant peut utiliser un serveur proxy Web comme Achilles pour convertir automatiquement certains caractères spéciaux tels que < en %3C, > en %3E. Lorsqu'une telle attaque se produit, les crochets angulaires sont généralement remplacés par des valeurs hexadécimales. dans l'URL.
L'expression régulière suivante détectera tout texte contenant <, > en HTML. Il interceptera les tentatives d'utilisation de <b>, <u> ou <script>. Cette expression régulière doit ignorer la casse. Nous devons détecter à la fois le crochet angulaire et son équivalent hexadécimal (% 3C|<). Pour détecter la chaîne entière convertie en hexadécimal, nous devons détecter les nombres et les signes % saisis par l'utilisateur, c'est-à-dire utiliser [a-z0-9%]. Cela peut provoquer l'apparition de quelques bugs, mais la plupart ne détecteront pas de véritables attaques.
3.1 Expression régulière pour les attaques CSS générales
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
Explication :
((%3C)|<) - vérifie < et son équivalent hexadécimal
((%2F)|/)* - balise de fermeture/ ou son équivalent hexadécimal
[a-z0-9%]+ - Vérifiez la lettre dans la balise ou son équivalent hexadécimal
((%3E)|>) - Recherchez > ou sa règle hexadécimale
Snort :
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg : "Tentative de script intersite NII" ; flux : vers le serveur, établi ; pcre : "/((%3C)|<)((%2F)| /)*[a-z0-9%]+((%3E)|>)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
Les scripts intersites peuvent également être utilisé< img src=>Technologie. Les règles actuelles de sniff par défaut peuvent être facilement contournées.
La section 3.2 fournit des méthodes pour empêcher cette technique.
3.2 Expression régulière d'attaque CSS "<img src"
/((%3C)|<)((%69)|i|(%49))((%6D)|m|(%4D) ) ((%67)|g|(%47))[^n]+((%3E)|>)/I
explication :
(%3 C)|<) -<ou son équivalent hexadécimal
(%69)|i|(%49))((%6D)|m|(%4D))((%67)|g|(%47) -'img' lettre ou il Combinaisons de variations d'équivalents hexadécimaux majuscules et minuscules
[^n]+ - tout caractère suivant <img sauf la nouvelle ligne
(%3E)|>) -> ou son équivalent hexadécimal
3.3 CSS Attack Extreme Regular Expression
/((%3C)|<)[^n]+((%3E)|>) /I
Explication :
Ceci La règle recherche simplement <+n'importe quel caractère sauf un caractère de nouvelle ligne+>. Selon l'architecture de votre serveur Web et de votre application Web, cette règle peut produire des erreurs. Mais il est garanti d’attraper toutes les attaques de type CCS ou CSS.
Résumé :
Dans cet article, nous avons proposé différents types de règles d'expression régulière pour détecter les attaques par injection SQL et par scripts intersites. Certaines règles sont simples et extrêmes, et une attaque potentielle vous alarmera. Mais ces règles extrêmes peuvent conduire à des erreurs proactives. Dans cet esprit, nous avons modifié ces règles simples pour utiliser des styles supplémentaires afin de pouvoir les vérifier avec plus de précision. Lors de la détection des attaques sur ces applications réseau, nous vous recommandons de les utiliser comme point de départ pour déboguer votre IDS ou vos méthodes d'analyse des journaux. Après quelques révisions supplémentaires, vous devriez être prêt à détecter ces attaques après avoir évalué les réponses non malveillantes à la partie normale des transactions réseau.
Référence
1. Injection SQL
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
2. FAQ sur les scripts intersites http://www.cgisecurity.com/articles/xss -
faq.shtml
3. L'IDS Snort http://www.snort.org
4. Expressions régulières compatibles Perl (pcre) http://www.pcre.org
5. Proxy d'application Web, Achilles http://achilles.mavensecurity.com
3. Injection SQL avancée
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
7. HOWTO de programmation sécurisée, David Wheeler www.dwheeler.com
8. Menaces et contre-mesures, MSDN, Microsoft