HTTP 302 sans SSL / set-cookie: ovh_challenge_cookie

Bonjour,

Cela ressemble à une vérification anti-robot suite à un comportement suspect de votre IP.

Cordialement, janus57

J'ai constaté que depuis mon pc l'acces se faisait ne ipv6 et la station meteo etait en ipv4, jai donc retiré le AAAA de la zone dns, flushdns, et jai refais un curl, et ca passe correctement en ipv4 depuis le PC.

Si je compare les deux requete, a part le nombre de parametre get de l'url et le user agent absent sur la requette de la station meteo, sinon jai aucune difference.

par contre dans la reponse il veut me rediriger vers la meme url avec seulement le premier parametre.... etrange.
si j'affiche la variable $_GET dans mon script, jai bien tout si je l'appel via navigateur, mais je ne sais pas si il m'a redirigé

Array
(
[ID] => IDStation
[PASSWORD] => MotDePasse
[action] => updateraww
[realtime] => 1
[rtfreq] => 5
[dateutc] => now
[baromin] => 30.72
[tempf] => 51.6
[dewptf] => 51.4
[humidity] => 99
[windspeedmph] => 0.0
[windgustmph] => 0.0
[winddir] => 156
[rainin] => 0.0
[dailyrainin] => 0.0
[solarradiation] => 0.0
[UV] => 0.0
[indoortempf] => 61.8
[indoorhumidity] => 61
)

e vérification anti-robot

effectivement, mais mon ip est la meme de la station ou de mon pc.

Je viens de faire un essais sans user agent :
curl -v http://weather.daspower.fr:80/weatherstation/updateweatherstation.php?PASSWORD=test --max-redirs 0 -H User-Agent:

et j'ai obtenu la reponse 302 !
OVH redirige les requetes sans user agent. y a t'il un moyen de les accepter sans redirection, sans le OVH_CHALLENGE_COOKIE ? :

Bonjour,

regardez dans votre hébergement si le firewall est activé, si la réponse est non et que OVH a fait un changement je dirais que vous êtes bloqué si vous ne pouvez pas faire de requêtes avec user-agent custom.

Cordialement, janus57

le firewall est bien desactivé, je ne suis pas seul dans ce cas, ca va etre plutot problématique si ovh ne fait rien.
sur le ticket que j'ai fais ils persistent a me dire que ca vient de mon code php :/

Bonjour,

théoriquement une requêtes HTTP devrait avoir un UA, donc à qui la faute, aucune idée, mais cela me semble pas spécialement anormale de refuser des requêtes sans UA si derrière cette technique est utilisé pour faire des attaques.

Cordialement, janus57

ca marchait depuis 2 ans, apres je peux mettre un proxy qui ajoute un UA, mais bon.. On devrait pouvoir l'autoriser pour certaines IP a la limite

hébergement si le firewall est activé, si la réponse est non et que OVH a fait un changement je dirais

Bonjour Janus57,
Vous sous entendez que nos problèmes viennent d'un firewall désactivé suite à une mise à jour d'OVH?
cela rejoint le topic https://community.ovhcloud.com/community/fr/erreur-403-application-click-once?id=community_question&sys_id=4b02d242dcfd56901e119f7f66c09493
Donc comment résoudre ce problème ?
cordialement

Après test, avec Firewall activé ou désactivé, le problème est le même...
il y a bien un soucis vis à vis de la gestion du UserAgent au niveau de votre firewall depuis le 30/10/204...

Oui je suis d'accord avec vous pour un UA généralisé. Avez vous appelez tous les constructeurs de firmware, applications pour leur avoir annoncé cela ?

avant de le bloquer ??

Bonjour,

Vous sous entendez que nos problèmes viennent d'un firewall désactivé suite à une mise à jour d'OVH?

non je dis que ce comportement était visible avant avec le firewall d'activé

Oui je suis d'accord avec vous pour un UA généralisé. Avez vous appelez tous les constructeurs de firmware, applications pour leur avoir annoncé cela ?

désolé si les constructeurs ne respectent pas les RFC pour les requêtes HTTP, mais c'est au client de râler auprès des constructeur quand celui-ci fait de le merde

avant de le bloquer ??

demander à OVH.

Dans tous les cas comme répondu par **un corp de OVH**, c'est bien ce que j'avais présenté => protection dans les attaques/requêtes illégitime :

Je vous confirme que nous travaillons régulièrement à l'amélioration des protections de nos infrastructures contre le trafic malveillant à destination de vos sites & applications.

Dans ce but, nous avons fait évolué le filtrage des accès sans user-agent, la pratique étant extrêmement présente dans le trafic illégitime que nous rencontrons actuellement.
Ce change a été déployé de manière très progressive sur les infrastructures depuis les 2 dernières semaines avec des phases d'attente et d'analyse pour nous assurer que le trafic légitime n'est pas impacté. Le déploiement est désormais terminé depuis ce mardi matin.

Cordialement, janus57

Bonjour,

J'ai exactement le même problème depuis 15h ce jour sur tous mes appels PHP file_get_contents et readfile : HTTP 302 / Temporary moved
Je n'ai jamais eu besoin de mettre de user-agent sur ces 2 fonctions.
Je vais faire un ticket dès demain matin.
Donc non, cela ne vient pas de notre code.

désolé si les constructeurs ne respectent pas les RFC pour les requêtes HTTP,

Donc les RFC disent SHOULD et non MUST

C'est OVH qui ne respecte pas les RFC. Point.

PHP file_get_contents

Entretemps vous pouvez vous dépanner avec ceci, semble-t-il (non testé)

https://gist.github.com/vyspiansky/82f4b1ef6fcff160047d

alors en effet, depuis hier j'ai ce cookie challenge sur une application native qui ne supporte pas la redirection 302...je pourrais corriger cela, mais l'application utilise justement sa requête pour faire sa mise à jour !

c'est un gros problème si on ne peut pas - ne serait-ce que temporairement- désactiver ce filtrage.

Bonjour,
Je suis d'accord avec cette proposition, le mieux est de fournir un user-agent propre.

Bruno B.

Bonjour,
Je me permet de linker ma réponse précédente au même point dans un autre fil
https://community.ovhcloud.com/community/fr/erreur-403-application-click-once?id=community_question&sys_id=4b02d242dcfd56901e119f7f66c09493?u=brunob-ovhcloud

Bruno B.

@BrunoB-OVHCloud dans la capture d'écran du premier poste, on voit l'url de redirection (location: ... ) qui est tronquée par rapport a ce qui est affiché un peu plus bas.

Bonjour,

La RFC qui définit le terme should n'est pas d'accord avec cet argument ou alors j'ai mal compris.

RFC 2119 :
[Quote]
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but **the full implications must be understood and carefully weighed before choosing a different course.**
[/quote]

Cordialement, janus57

"le mieux" c'est de permettre de désactiver ce filtre le temps que les applications - qui utilisent cette requête HTTP sans le support 302 pour ce mettre à jour - puissent se mettre à jour !

Notre souhait n'est pas de baisser la garde mais plutôt de gérer au mieux les usecases de nos clients.
C'est pour cela que j'ai besoin d'infos, sans cela, avec l'équipe nous aurons du mal à vous aider.

--
Bruno B.

J'ai demandé un firmware custom avec un user agent mais je doute fortement qu'ils en developpent un pour mes beaux yeux.
donc en attendant je suis bloqué puisque vous ne semblez pas vouloir nous laisser la main sur l'activation de ce filtre, ou nous donner la possibilité d'ajouter des exceptions.

donc pour mon "usecase" c'est tempi pour moi si je comprend bien ?

Je tiens à ajouter quelques petites choses à la discussion. La validation du UserAgent n'est et n'a jamais été un gage de sécurité. N'importe quel bot ou outil de pentest permet d'ajouter un header user-agent à ses requêtes et ne parlons même pas des attaques manuelles.

On ne va pas se mentir, là où aujourd'hui peut être seulement **50% des clients lourds métier** communiquant avec des webservices fournissent un user agent. **99% des outils de hacking** envoie eux un user agent, simplement parce que ça ne leur coute rien et que c'est leur but de se faire passer pour un browser légitime.

Les user-agents ont initialement été utilisé pour être capable d'identifier un browser et servir une page compatible au client. En particulier lorsque nous n'avions pas la même mouture de Javascript sur IE / Firefox / Safari. Ou encore à des fins de statistiques.

Aujourd'hui encore, la majorité des calls vers des web services, n'intègrent toujours pas de user-agent à leur requêtes car effectivement ceci est optionnel (**Should** et non **must**) Et ne parlons pas des client lourds qui n'ont dans la plus part des cas pas de User Agent officiel ou valide.

Pour ma petite histoire personnelle, j'utilise un service de tunnel de vente sur lequel je n'ai pas la main qui envoie des informations vers mon serveur OVH, cette communication inter webservice n'inclue pas de UA donc depuis deux jours, plus rien de fonctionne.

Je suis seulement un des nombreux client du service de tunnel de vente, je n'ai pas la main sur les requêtes qu'ils génèrent. Par contre je suis client OVH et propriétaire de mon serveur, ce dernier devrait donc être sous ma responsabilité, et je devrait être capable d'accepter les requêtes sans UA parce qu'elles ne sont dans les fait pas plus dangereuses que n'importe quelle autre requêtes.

Ma seule option aujourd'hui c'est espérer qu'OVH permette de gérer ce paramètre manuellement depuis le fichier .ovhconfig ou depuis l'interface d'administration ou encore, ce qui serait presque logique, d'avoir cette option activée uniquement lorsque l'option WAF est activée sur mon hébergement.

Autre solution, passer chez un hébergeur qui respecte les RFC. Les RFC c'est comme les good behavior en aviation, si il n'y a pas de crash, elles n'ont pas de raison d'évoluer. Comme lu plus haut, la RFC en question a 10 ans. Effectivement et elle est toujours en service c'est à dire que sur cette RFC en particulier personne n'a jugé qu'il y avait un problème majeur impliquant des incidents de sécurité en 10 ans. Sauf peut être OVH..

Bonjour,
Je tiens à préciser que nous ne bloquons pas les user-agent, nous continuons de respecter la RFC mais nous challengeons les requêtes qui arrivent sans user-agent pour en filtrer une partie.
Le fait d'être sur des infrastructures mutualisées ne rend pas un service indépendant et donc proposer à nos clients d'activer sur la base du volontariat la fonctionnalité ne nous permet pas d'assurer ce filtrage très efficace à l'échelle.
Toutefois, nous travaillons à des adaptations du process pour prendre en compte les feedbacks.

Bruno B.

@BrunoB-OVHCloud, si un équipement n'est pas en mesure de fournir un user agent il pourra encore moins suivre une redirection, qui est d'autant plus est erronée. ni accepter un cookie.
donc ca revient a bloquer,vous me laissez sans solution...
Vous nous demandez des cas précis mais quand on vous en fourni on a pas de reponse.

Bonjour,
Il y a énormément de clients http, la majorité qui valident le challenge ajouté.
Nous n'arrivons pas à reproduire une requête tronquée dans la 302, sur les cas testés, la redirection est bien complète.
Par contre certains outils tronquent le log, et le formatage de votre capture d'écran me fait penser à cela, requête trop longue pour le log.
Nous travaillons à une solution de mitigation limitée, une communication arrive sous peu

Bruno B.

non ce n'est pas tronqué, ici les données brutes :


Le deuxieme parametre dans l'url est appelé "PASSWORD" ne serait-ce pas un mot clé refusé ?

Vous avez mal lu mon message, je parle bien de bloquer les requêtes sans user-agent. J'ai bien compris la solution que vous avec implémenté:

Si une requête arrive sans user-agent, on envoie un cookie de validation et un status HTTP 302 dans certain cas on envoie directement un 403 forbidden.

Cette modification implique dans tous les cas une modification côté client:
- Ajouter un user agent
ou
- Ajouter la prise en charge de la réponse 302 et réinjection du Cookie

Sauf que les services web tel que Microsoft Click once, E-junkie, et même certaines webrequest Paypal n'utilisent pas de user-agent.

Dois t'on demander à des entreprises comme Paypal et Microsoft des mises à jour de leur côté pour se rendre compatible avec OVH?

Je ne parle pas des carte électroniques tel que je l'ai vu sur un autre message, les entreprises concernées doivent elle remplacer les cartes électroniques chez leur clients? Ou publier une update du firmware si ceci est possible? (Spoiler alert: ce n'est pas possible si leur communications avec leur service d'upgrade passe par OVH, en effet, les requêtes de mise à jour seront également bloquées)
Leur seule solution reste de prendre un hébergement chez un concurrent et de mettre à jour leur nom de domaine pour pointer vers le nouvel hébergement qui lui ne bloque pas ces requêtes pourtant légitimes.

Je me permet de vous demander un seul exemple concret de l'utilité de "**ce filtrage très efficace à l'échelle.**"

Je travaille dans le domaine du WAF depuis 15 ans, jamais un filtrage de missing user agent n'a été jugé comme efficace. Vous pouvez en revenche effectivement appliquer un filtrage sur les user-agent avec une blacklist car certains outils de test de sécurité ont leur propre user agent, même si celui ci reste modifiable dans les options. (W3AF, Acunetix, et j'en passe) Mais hors mis peut être quelques script kiddies incapable de modifier un user agent dans les options de leur outil de pentest vous ne bloquez aucune attaque digne de ce nom avec un filtrage de user-agent.

Sébastien

Pour des raisons évidentes de sécurité, je ne rentrerais pas dans le détail de ce qui filtré actuellement, mais nous parlons de dizaines de millions de requests qui sont légitimement refusées.

Pour la solution à vos problématiques, je vous propose de consulter mon message posté sur l'autre fil portant sur ce sujet.
https://community.ovhcloud.com/community/fr/erreur-403-application-click-once?id=community_question&sys_id=4b02d242dcfd56901e119f7f66c09493?u=brunob-ovhcloud

--
Bruno B.