Longueur maxi requête HTTP (pour CherryPy)

Le
Méta-MCI \(MVP\)
Bonjour !

Depuis quelques heures, j'ai un serveur qui n'arrête pas de recevoir des
requêtes HTTP d'une taille oscillant entre 59000 et plus de 65000
caractères.
Cela plante le serveur WSGI de CherryPy (qui, heureusement, se récupère
tout seul, derrière).

Du coup, je me posais la question de la taille maxi d'une requête HTTP.

Quelqu'un le saurait-il ? Ou dois-je me plonger dans l'océan gougueul ?

@+

Michel Claveau
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #3867711
À (at) Wed, 16 Apr 2008 15:29:26 +0200,
"Méta-MCI (MVP)"
Depuis quelques heures, j'ai un serveur qui n'arrête pas de recevoir
des requêtes HTTP d'une taille oscillant entre 59000 et plus de 65000
caractères.
Cela plante le serveur WSGI de CherryPy (qui, heureusement, se
récupère tout seul, derrière).

Du coup, je me posais la question de la taille maxi d'une requête HTTP.

Quelqu'un le saurait-il ? Ou dois-je me plonger dans l'océan gougueul ?


Le protocole HTTP lui-même n'impose aucune limite sur la taille d'une
requête ou d'une réponse.

Les serveurs Web tel Apache ont leur propre limite interne (2Go pour
Apache) et proposent généralement un réglage pour fixer cette limite
(directive 'LimitRequestBody' pour Apache).

Ensuite, chaque application peut choisir sa propre limite et donc
décider de stoper la réception dès cette limite atteinte. Les bonnes
bibliothèques CGI (ou les frameworks plus évolués) ont un paramètre
permettant de fixer cette limite par application.

--
Paul Gaborit -
William Dode
Le #3867701
On 16-04-2008, Méta-MCI (MVP) wrote:
Bonjour !

Depuis quelques heures, j'ai un serveur qui n'arrête pas de recevoir des
requêtes HTTP d'une taille oscillant entre 59000 et plus de 65000
caractères.


En GET ou en POST ?

Il y a bien des limites au niveau de la taille de l'url mais c'est au
niveau des navigateurs, par contre en post je ne pense pas...

Cela plante le serveur WSGI de CherryPy (qui, heureusement, se récupère
tout seul, derrière).


Si tu fais la requete toi-même (en python) ça le plante aussi oubien
est-ce seulement si ça vient d'un navigateur ?

--
William Dodé - http://flibuste.net
Informaticien indépendant

Méta-MCI \(MVP\)
Le #3910971
Bonsoir !

En GET ou en POST


Les deux.
Les attaques ont cessé. CherryPy ayant renvoyé systématiquement un "500
Internal Server error", le système d'attaque a dû déduire que ce n'était
pas Apache, ni IIS, et donc que les failles cherchées n'existaient pas.

En fait, des attaques, ou plutôt des tentatives (des scans), il en
arrive entre 50 et 100 par heure. Mais c'est la première fois que je
vois une erreur dans CherryPy ("Error in conn.communicate ;
wsgiserver__init__.py").

Sinon, les tentatives que je vois passer ont presque toujours la même
démarche : envoi d'un ensemble de requêtes cherchant à cibler Apache
(les 3/4 des scans) ou IIS (1/4 des scans). En l'absence de réponse
correspondantes à la cible visée, le scan cesse. Cela dure 1 ou 2
minutes.

Pour m'amuser, j'ai quelquefois essayé de remonter (tracert) les scans.
Et, chose curieuse, dans la plupart des cas, on aboutit sur des serveurs
universitaires (européens, américiains, australiens, canadiens).
Maintenant, savoir si ça provient des universitées elles-mêmes, ou s'il
s'agit de serveurs relais / corrompus, ou de machines zombies connectées
à ces serveurs, c'est une autre histoire.

La conclusion, c'est que CherryPy (et donc Python) tient bien la route,
côté sécurité Web. Car, même en cas d'erreur, le logiciel retombe sur
ses pattes.

@-salutations

Michel Claveau

Publicité
Poster une réponse
Anonyme