web-dev-qa-db-fra.com

(JSON :: ParserError) "{N}: jeton inattendu sur 'alihack <demande% eval (\" alihack.com\")%>

J'ai le site Web sur Ruby on Rails 3.2.11 et Ruby 1.9.3. 

Qu'est-ce qui peut causer l'erreur suivante:

(JSON::ParserError) "{N}: unexpected token at 'alihack<%eval request(\"alihack.com\")%>

J'ai plusieurs erreurs comme celle-ci dans les journaux. Tous essaient d’évaluer la demande (\ "alihack.com \"). 

Une partie du fichier journal:

"REMOTE_ADDR" => "10.123.66.198",
"REQUEST_METHOD" => "PUT",
"REQUEST_PATH" => "/ALi.txt",
"PATH_INFO" => "/ALi.txt",
"REQUEST_URI" => "/ALi.txt",
"SERVER_PROTOCOL" => "HTTP/1.1",
"HTTP_VERSION" => "HTTP/1.1",
"HTTP_X_REQUEST_START" => "1407690958116",
"HTTP_X_REQUEST_ID" => "47392d63-f113-48ba-bdd4-74492ebe64f6",
"HTTP_X_FORWARDED_PROTO" => "https",
"HTTP_X_FORWARDED_PORT" => "443",
"HTTP_X_FORWARDED_FOR" => "23.27.103.106, 199.27.133.183".

199.27.133.183 - is CLoudFlare IP . "REMOTE_ADDR" => "10.93.15.235" et "10.123.66.198" et d'autres, je pense, sont de fausses adresses IP de proxy.

Voici un lien guy a le même problème avec son site web à partir de la même adresse IP (23.27.103.106).

Pour résumer, l'adresse IP commune à toutes les erreurs est 23.27.103.106 et ils essaient d'exécuter le script à l'aide de eval de Ruby.

Mes questions sont donc les suivantes: Quel type de vulnérabilité ils essaient de trouver? Que faire? Bloquer l'ip?

Merci d'avance.

ruby-on-railsrubyjsonruby-on-rails-3
53
Igor Markelov

Pourquoi ça arrive?

Cela ressemble à une tentative de test ou d’exploitation d’une vulnérabilité d’exécution de code à distance. Potentiellement générique (ciblant une plate-forme autre que Rails) ou existant dans les versions précédentes.

L'erreur réelle provient toutefois du fait que la demande est un HTTP PUT avec des en-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'analyser les requêtes JSON en transmettant 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, ce n'est pas un JSON valide, et l'erreur est générée, ce qui entraîne le serveur à signaler un 500.

Solutions possibles

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

  1. vous pouvez bloquer l'adresse IP en utilisant iptables
  2. filtrer (PUT ou tout) demandes à /ALi.txt dans vos configs nginx ou Apache.
  3. utilisez un outil comme le rack-attack gem et appliquez le filtre à cet endroit. (voir ceci problème d'attaque de rack )
  4. utilisez le request_exception_handler gem pour détecter l'erreur et la gérer depuis Rails (voir cette SO réponse et ce problème de github )
  5. bloquer les requêtes PUT dans le routes.rb de Rails à toutes les URL sauf celles explicitement autorisées. Il semble que dans ce cas, l'erreur est générée avant même qu'elle n'atteigne les routes de Rails - de sorte que cela pourrait ne pas être possible.
  6. Utilisez le rack-robustness middleware et interceptez l'erreur d'analyse json avec quelque chose comme cette configuration in config/application.rb
  7. Ecrivez votre propre middleware. Quelque chose dans le sens du contenu de ce post

Je suis actuellement penché vers les options n ° 3, n ° 4 ou n ° 6. Ce qui pourrait être utile pour d’autres types de robots/scanners ou d’autres requêtes invalides qui pourraient apparaître à l’avenir ...

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

65
gingerlime

J'ai vu des entrées de journaux étranges sur mon propre site [qui n'utilise pas Ruby] et Google m'a conduit à ce fil. L'adresse IP de mes entrées était différente. [120.37.236.161]

Après avoir fouillé un peu plus, voici ma conjecture principalement éclairée:

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

Il y a aussi une page "register.php" - la soumission vous mè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 m'attends à ce que cet outil "Black Spider" ait été modifié par un script pour enfants et soit utilisé comme un bombardier en tapis pour tenter de trouver des sites "vulnérables".

Il peut être prudent d'ajouter simplement un déni automatique de toute tentative incluant la sous-chaîne "alihack" à votre configuration.

10
CRZ

Un problème similaire s'est présenté dans mes journaux de barre mobile, une demande PUT à /ALi.txt

Le mieux étant de bloquer cette adresse IP, je n'ai vu qu'une seule demande avec cette erreur. La demande que j'ai reçue venait de France -> http://whois.domaintools.com/37.187.74.201

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

deny 23.27.103.106/32;
deny 199.27.133.183/32;
2
Jamsi

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

0
Kostia