Comprendre les requêtes d'attaque HTTP GET
J'ai capturé quelques attaques Web. J'essaie de comprendre à quoi sert chaque demande d'attaque.
GET /site/public/timing?<!+XSS="><img+src=xx:x+onerror=alert(14721850.00337)//"> HTTP/1.1" 200 6718
GET /site/public/timing?<sVg/OnLOaD=Prompt(14721850.00307)> HTTP/1.1" 200 6718
GET /site/race/registrationAuth/1761?x"+onmousemove=" HTTP/1.1" 302 -
GET /site/registration/create/3269?execution=e1s1'+(select*from(select(sleep(3)))tw)+' HTTP/1.1" 302 -
GET /site/registration/create/3269?execution=e1s1%20waitfor delay'0:0:3'
Cela ressemble à des attaques automatisées pour tester différentes vulnérabilités d'injection. Autant que je sache, il n'y a pas de véritable charge utile malléable ici. Les attaques sont plutôt conçues pour détecter si le site est vulnérable. Je suppose que les sites seront attaqués avec des charges utiles réelles si les tests sont positifs.
Les trois premiers sont XSS attaques. Les deux premiers essaieront de faire apparaître une invite avec le numéro 14721850.00337 dedans. Si vous multipliez ce nombre par 100, vous obtenez un horodatage Unix qui était il y a trois jours. Je suppose qu'il est utilisé pour chronométrer l'attaque d'une manière ou d'une autre.
Quelques astuces courantes pour tromper les filtres sont utilisées - mIxeD CAsE, Prompt au lieu de alert, / au lieu de l'espace.
Les quatrième et cinquième tests pour injection SQL . Il essaie de faire "dormir" le serveur de base de données pendant un certain temps. Cela permet de vérifier facilement si l'attaque a réussi. Si cela prend quelques secondes pour obtenir une réponse, cela a fonctionné. Je pense que le quatrième est destiné à MySQL et le cinquième à MSSQL, mais ils pourraient également fonctionner sur d'autres systèmes.
Avez-vous donc besoin d'être inquiet? Pas vraiment. Ce type d'attaques automatisées est courant contre tous les serveurs Internet. Cela ne signifie pas nécessairement que quelqu'un vous attaque spécifiquement ou que vous êtes vulnérable. Mais tout de même, c'est probablement une bonne idée de tester si les attaques fonctionnent ou non, car si elles le faisaient, vous pouvez être sûr qu'elles ont été exploitées maintenant.
Toutes ces demandes semblent provenir d'un outil de test automatisé. Contrairement à ce que certains commentaires disent, les retards ne sont pas malveillants, juste pour tester aveuglément l'exécution de code; si vous ne voyez pas de réponse, le laisser dormir pendant un nombre défini de secondes est un test fiable.
GET /site/public/timing?<!+XSS="> <img+src=xx:x+onerror=alert(14721850.00337)//"> HTTP/1.1" 200 6718
GET /site/public/timing?<sVg/OnLOaD=Prompt(14721850.00307)> HTTP/1.1" 200 6718
XSS tente, essaie d'alerter 14721850.00307/337 pour voir si la page est vulnérable.
GET /site/race/registrationAuth/1761?x"+onmousemove=" HTTP/1.1" 302 -
Un peu flou, pas de code fonctionnel. Ressemble à XSS utilisant un gestionnaire d'événements pour contourner les filtres
GET /site/registration/create/3269?execution=e1s1'+(select*from(select(sleep(3)))tw)+' HTTP/1.1" 302 -
Attaque MySQL v5. Malgré l'instruction SELECT, il essaie seulement de laisser le serveur dormir pendant 3 secondes pour voir s'il est vulnérable.
GET /site/registration/create/3269?execution=e1s1%20waitfor delay'0:0:3'
Attaque Microsoft SQL Server. Même histoire, pas de code malveillant, juste un seul retard de 3s.
1 & 2: Quelques injections XSS
3: Très probablement aussi un XSS
4: injection SQL (vidage de la base de données)
5: injection T-SQL (sonde SQL)
Rappelez-vous que certains bots jettent simplement des choses derrière une URL pour voir si quelque chose revient, ce sont des cibles non spécifiques (test fuzz). Les en-têtes reçus sont ensuite vérifiés pour 200 ou un autre code HTTP sans erreur. De plus, en randomisant la requête GET, l'attaquant peut ingorer les résultats mis en cache ou contourner les mesures de sécurité.
Pas sûr à 100%, mais la première et la seconde ressemblent à des attaques de script. Ils essaient tous les deux d'injecter JavaScript qui émet une alerte ou une invite avec un numéro particulier - rien de dangereux en soi, mais il teste si cela est possible.
Le troisième essaie d'ajouter un événement onmousemove . Je pense qu'il essaie de faire en sorte que l'utilisateur envoie une demande chaque fois qu'il déplace sa souris. Pourquoi cela sent-il comme une attaque par déni de service?
La quatrième ressemble à une injection SQL: elle demande tout à partir des résultats d'une autre requête. Je ne sais pas ce que fait cette autre requête, mais je pense qu'elle est censée attendre trois secondes et ne rien faire.
Le cinquième est un injection SQL aveugle . Celui-ci indique à une base de données SQL Server d'attendre trois secondes; s'il revient avec succès, la base de données peut être attaquée.