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 ?
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 - <http://perso.enstimac.fr/~gaborit/>
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 - <http://perso.enstimac.fr/~gaborit/>
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 - <http://perso.enstimac.fr/~gaborit/>
William Dode
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
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
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\)
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
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.
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.
