Puis-je faire confiance à l'IP source d'une requête HTTP?
Pour autant que je sache, si vous essayez d'émettre une demande HTTP avec une adresse IP usurpée, la poignée de main TCP échoue, il n'est donc pas possible de terminer la demande HTTP, car le SYN/ACK du serveur n'atteint pas le mauvais client ...
... dans la plupart des cas. Mais laissons maintenant de côté ces quatre cas:
- Man in the middle (MITM) attaque
- Le cas où le client malveillant contrôle le réseau du serveur Web
- Le cas où le client malveillant simule une autre IP sur son propre réseau local
- attaques BGP
Alors je peux en effet faire confiance à l'adresse IP d'une requête HTTP?
Contexte: Je pense à construire une carte des adresses IP et de l'utilisation des ressources, et à bloquer les adresses IP qui consomment trop de ressources. Mais je me demande s'il existe, par exemple, un moyen de truquer un nombre infini d'adresses IP (en émettant des requêtes HTTP réussies avec des adresses IP truquées), de sorte que le serveur resource-usage-by-IP- du serveur Web buffers grossit et provoque des erreurs de mémoire insuffisante.
(Hmm, peut-être qu'un mauvais routeur Internet pourrait truquer de très nombreuses requêtes. Mais ce n'est pas le cas, n'est-ce pas. (Ce serait une attaque MITM? C'est pourquoi j'ai dit surtout mépris, ci-dessus))
Oui (avec vos hypothèses de négliger le client capable d'intercepter le retour de la poignée de main à une adresse IP usurpée) si vous faites les choses correctement. Les requêtes HTTP sont effectuées via TCP; tant que la négociation n'est pas terminée, le serveur Web ne démarre pas le traitement de la demande HTTP. Certes, un utilisateur aléatoire pourrait tenter d'usurper la fin d'une poignée de main; mais comme ils doivent deviner le ACK généré par le serveur, ils ne devraient avoir qu'une chance sur 2 ^ 32 (~ 4 milliards) de réussir à chaque fois.
Comme l'a dit Ladadadada, assurez-vous que vous ne récupérez pas la mauvaise valeur de l'adresse IP distante dans votre application Web. Vous voulez l'adresse IP du en-tête de datagramme IP (en particulier, l'adresse IP source). Vous ne voulez pas de valeurs comme X-Forwarded-For/X-Real-IP qui peuvent être forgées trivialement car elles sont définies dans l'en-tête HTTP. Testez définitivement en essayant d'usurper certaines adresses IP; avec par exemple un plugin de navigateur ou manuellement avec telnet yourserver.com 80.
Le but de ces champs est que les mandataires Web (qui peuvent dire que le contenu du cache le serve plus rapidement) puissent communiquer aux serveurs Web la véritable adresse IP de l'utilisateur plutôt que l'adresse IP des mandataires (qui peut être pour des centaines d'utilisateurs). Cependant, comme tout le monde peut définir ce champ, il ne doit pas être approuvé.
Puis-je faire confiance à l'IP source d'une requête HTTP?
Vous pouvez être raisonnablement assuré que l'adresse IP source d'une demande HTTP est l'adresse source de la connexion TCP qui a généré la demande.
Quand faire confiance à une adresse IP est une question contextuelle complexe, mais ce n'est pas vraiment ce que vous demandez.
vous vous inquiétez de l'impact de l'utilisation/de l'implémentation de limites de débit par IP au niveau de la couche application et de toute vulnérabilité supplémentaire aux attaques par déni de service?
Je me demande si cela, dans la couche d'application, introduit des vulnérabilités supplémentaires, oui.
Cela dépend entièrement de votre mise en œuvre, à la fois politique et technologique.
- De quel type de ressource voulez-vous évaluer la consommation limite?
- Que voulez-vous réaliser en créant cette limite de taux?
- Sur quelle période souhaitez-vous effectuer la comptabilité?
- Où voulez-vous appliquer la limite?
- L'adresse IP est-elle la meilleure clé pour la limite de débit?
- Quelles sont les raisons probables d'une surconsommation?
- Quelle devrait être l'expérience utilisateur en cas de surconsommation?
Selon les réponses à ces questions, la limite de taux peut être mieux placée ailleurs dans l'infrastructure de service, par ex. pare-feu dédié, pare-feu local. Ou si l'accès est authentifié, les informations d'identification authentifiées peuvent être une meilleure clé pour la comptabilité des taux et vos limites seraient définies.
À quoi servirait d'émettre un SYN usurpé sur un serveur HTTP si vous n'avez pas l'intention de continuer la TCP poignée de main? Votre serveur web ne verra pas la requête HTTP à moins que (éventuellement falsifié) le client obtient le SYN/ACK et continue d'établir la session TCP, et envoie une requête HTTP.
Stockez la base de données sur le disque, structurez-la intelligemment (comme un arbre) pour des recherches rapides.
Si le client est usurpé ou non, cela fait-il vraiment une différence pour vous? S'ils se conduisent mal, ils se conduisent mal, peu importe s'ils sont usurpés ou non.
Du point de vue du serveur Web, je considérerais que l'IP distante est la véritable IP distante.