(JSON :: ParserError) “{N}: jeton inattendu à la requête ‘alihack

Pourquoi ça arrive?

Cela semble être une tentative pour au moins tester ou exploiter une vulnérabilité d’exécution de code à distance. Potentiellement générique (ciblant une plate-forme autre que Rails) ou existante dans les versions antérieures.

L’erreur réelle provient toutefois du fait que la requête est un HTTP PUT avec application/json têtes application/json , mais que le corps n’est pas un json valide.

Pour reproduire cela sur votre environnement de développement:

curl -D - -X PUT --data "not json" -H "Content-Type: application/json" http://localhost:3000

Plus de détails

Rails action_dispatch tente d’parsingr toutes les requêtes json en passant le corps à décoder

  # lib/action_dispatch/middleware/params_parser.rb def parse_formatted_parameters(env) ... strategy = @parsers[mime_type] ... case strategy when Proc ... when :json data = ActiveSupport::JSON.decode(request.body) ... 

Dans ce cas, il ne s’agit pas d’un fichier JSON valide et l’erreur est générée, ce qui entraîne le rapport du serveur 500.

Solutions possibles

Je ne suis pas tout à fait sûr de la meilleure stratégie pour y faire face. Il y a plusieurs possibilités:

1. vous pouvez bloquer l’adresse IP en utilisant iptables
2. filtrer ( PUT ou toutes) les requêtes vers /ali.txt dans vos /ali.txt nginx ou apache .
3. Utilisez un outil tel que le joyau d’ rack-attack et appliquez le filtre à cet endroit. (voir ce problème d’attaque en rack )
4. utiliser la gem request_exception_handler pour détecter l’erreur et la gérer depuis Rails (voir cette réponse SO et ce problème github )
5. bloquer les requêtes PUT dans les routes.rb de Rails vers toutes les URL mais celles qui sont explicitement autorisées. Il semble que dans ce cas, l’erreur soit augmentée avant même qu’elle n’atteigne les routes de Rails – cela pourrait donc ne pas être possible.
6. Utilisez le middleware de rack-robustness du rack-robustness et attrapez l’erreur d’parsing de json avec quelque chose comme cette configuration dans config/application.rb
7. Ecrivez votre propre middleware. Quelque chose du genre des choses sur ce post

Je me penche actuellement sur les options # 3, # 4 ou # 6. Tout cela peut s’avérer utile pour d’autres types de bots / scanners ou d’autres requêtes non valides susceptibles de s’afficher à l’avenir …

Heureux d’entendre ce que les gens pensent des différentes solutions alternatives

J’ai vu des entrées de journal bizarres sur mon propre site [qui n’utilise pas Ruby] et Google m’a amené à ce sujet. L’IP sur mes entrées était différente. [120.37.236.161]

Après avoir fouillé un peu plus, voici ma supposition surtout spéculative / éduquée:

Premièrement, dans mes propres journaux, j’ai vu une référence à http://api.alihack.com/info.txt – vérifié ce lien; ressemblait à une tentative d’injection PHP.

Il y a aussi une page “register.php” – la soumission vous amène à une page “invite.php”.

Un examen plus approfondi de ce domaine m’a amené à http://www.alihack.com/2014/07/10/168.aspx (la page est en chinois mais Google Translate m’a aidé ici)

Je pense que cet outil “Black Spider” a été modifié par des script kiddies et est utilisé comme un bombardier de tapis pour tenter de trouver des sites “vulnérables”.

Il pourrait être prudent d’append un déni automatique de toute tentative incluant la sous-chaîne “alihack” à votre configuration.

J’ai eu un problème similaire apparaître dans mes journaux Rollbar, une demande PUT à /ali.txt

Mieux encore, pour bloquer cette adresse IP, je n’ai vu qu’une seule demande avec cette erreur. La demande que j’ai reçue vient de France -> http://whois.domaintools.com/37.187.74.201

Si vous utilisez nginx, ajoutez-le à votre fichier de configuration nginx;

 deny 23.27.103.106/32; deny 199.27.133.183/32; 

Pour Rails-3, il existe une solution de contournement spéciale: https://github.com/infopark/robust_params_parser