Quel est le niveau de sécurité d’un HTTP POST?

Un POST est-il suffisamment sécurisé pour envoyer des identifiants de connexion?

Ou une connexion SSL est-elle indispensable ?

SSL est un must. POST n’est pas plus sécurisé que GET car il est également envoyé en clair. SSL couvrira toute la communication HTTP et chiffrera les données HTTP envoyées entre le client et le serveur.

J’ai un article de blog qui détaille à quoi ressemble une requête HTTP et comment une requête GET se compare à une requête POST. Par souci de concision, GET:

 GET /?page=123 HTTP/1.1 CRLF Host: jasonmbaker.wordpress.com CRLF User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 CRLF Connection: close CRLF 

et POST:

 POST / HTTP/1.1 CRLF Host: jasonmbaker.wordpress.com CRLF User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 CRLF Connection: close CRLF CRLF page=123 

(Le CRLF est juste une nouvelle ligne)

Comme vous pouvez le voir, les seules différences du sharepoint vue de la formation d’une requête * sont qu’une requête POST utilise le mot POST et que les données du formulaire sont envoyées dans le corps de la requête par rapport à l’URI. Ainsi, l’utilisation de HTTP POST est la sécurité par obscurité. Si vous souhaitez protéger les données, vous devez utiliser SSL.

* Notez qu’il existe d’ autres différences .

Cela dépend de votre situation, combien l’interception des informations d’identification coûterait à quelqu’un?

S’il ne s’agit que d’une connexion à un site Q + A logiciel, SSL peut ne pas être nécessaire, s’il s’agit d’un site bancaire en ligne ou si vous stockez des données de carte de crédit, c’est le cas.
Ceci est une affaire et non une décision technique.

HTTP POST n’est pas chiffré, il peut être intercepté par un renifleur de réseau, par un proxy ou par une fuite dans les journaux du serveur avec un niveau de consignation personnalisé. Oui, le test POST est meilleur que GET car les données POST ne sont généralement pas consignées par un proxy ou un serveur, mais elles ne sont pas sécurisées . Pour sécuriser un mot de passe ou d’autres données confidentielles, vous devez utiliser SSL ou chiffrer les données avant de les envoyer. Une autre option serait d’utiliser l’authentification Digest avec le navigateur (voir RFC 2617). Rappelez-vous que le cryptage (développé en interne) n’est pas suffisant pour empêcher les attaques par relecture, vous devez concaténer un nonce et d’autres données (par exemple, royaume) avant de les chiffrer (voir la RFC 2617 dans Digest Auth).

SSL est un must 🙂

HTTP Post est transmis en texte brut. Par exemple, téléchargez et utilisez Fiddler pour regarder le trafic HTTP. Vous pouvez facilement voir l’intégralité du message là-bas (ou via un moniteur de trafic réseau comme WireShark)

Ce n’est pas sécurisé Un POST peut être détecté aussi facilement qu’un GET.

Non … POST n’est pas assez sécurisé du tout. SSL est un MUST.

POST ne masque efficacement que les parameters de la chaîne de requête. Ces parameters peuvent toujours être captés par quiconque regarde le trafic entre le navigateur et le point final.

Le moyen le plus sûr consiste à ne pas envoyer d’informations d’identification du tout.

Si vous utilisez l’ authentification Digest , le protocole SSL n’est PAS obligatoire.

(NB: Je ne sous-entends pas que l’authentification Digest via HTTP est toujours plus sécurisée que l’utilisation de POST via HTTPS).

Le POST est en clair.

Une connexion sécurisée est indispensable.

C’est pourquoi cela s’appelle une connexion sécurisée.

Non, utilisez SSL.

Avec POST, les valeurs sont toujours soumises en texte brut sauf si SSL est utilisé.

La seule différence entre HTTP GET et HTTP POST est la manière dont les données sont codées. Dans les deux cas, il est envoyé en texte brut.

Afin de fournir tout type de sécurité pour les identifiants de connexion, HTTPS est un must.

Vous n’avez pas besoin non plus d’un certificate coûteux pour fournir HTTPS. De nombreux fournisseurs délivreront des certificates très basiques pour environ 20 USD. Les plus coûteuses comprennent la vérification de l’identité, qui est plus préoccupante pour les sites de commerce électronique.

Une requête POST seule n’est pas sécurisée car toutes les données sont “en déplacement” en texte brut.

Vous avez besoin de SSL pour le sécuriser.

Les données POST sont envoyées en texte brut si vous utilisez une connexion HTTP non cryptée. Si cela est suffisamment sécurisé, cela dépend de votre utilisation (indice: ce n’est pas le cas).

Si le serveur, la machine client et TOUTES LES MACHINES ENTRE LES MACHINES font partie d’un réseau contrôlé et entièrement sécurisé, cela peut être correct.

En dehors de ces circonstances très limitées (et parfois même à l’intérieur de celles-ci), l’authentification par texte brut pose problème.

S’il vous plaît voir cet excellent article:

Protéger contre les demandes POST malveillantes

https://perishablepress.com/protect-post-requests/