-
Vincent Mazenod authoredVincent Mazenod authored
- client / serveur
- HTTP
- HTTP
- URI/URL/URN
- Schéma d'url
- urls trompeuses
- requête HTTP
- requête HTTP de la vraie vie
- verbes HTTP
- verbes HTTP
- réponse HTTP
- réponse HTTP de la vraie vie
- les codes HTTP
- les codes d'erreur HTTP
- les codes d'erreur HTTP
- paramètres HTTP
- REpresentational State Transfer
- REpresentational State Transfer
- Exemple
- HTTP est "stateless"
- les cookies
- les cookies
- les sessions
- local storage
- header, cookie, body, query string, script ...
http.md 9.58 KiB
client / serveur
HTTP
- le serveur est typiquement un serveur web
- le truc est typiquement une ressource associée a une URI
- le client est typiquement
- un navigateur web
- une web app
- un objet connecté
- n'importe quoi qui consomme de l'API...
HTTP
- inventé par Tim Berners-Lee en 1989
- version 1.1 jusqu'à 1999
-
version 2.0
- basée sur SPDY de Google
Note:
- périmètre de sécurité élargi browser / responsive / web app / API -> installé sur les mobiles
- Tim Berners Lee a également inventé les adresses web et le langage HTML qui forment le web
- URI terme le plus générique
- URN sans le protocole
- URL emplacement à suivre ne gère pas le déplacement de la ressource
URI/URL/URN
- Uniform Resource name (URN)
- ex: le nom d'une personne
- Uniform Resource locator (URL)
- ex: l'adresse d'une personne
- Uniform Resource Identifier
- des URLs, URNs, ou les deux Note:
- URI terme le plus générique
- URN sans le protocole, ca désigne le concept
- URL emplacement ou on peut trouver le concept
- ne gère pas le déplacement de la ressource
Schéma d'url
les mots de passes peuvent transiter en claire via les schemas d'url
urls trompeuses
- http://www.visa.com:1337@33.32.323.22:8080/cart?add=1345
- http://visa.com:UserSession=56858&useroption=879@42.216.64.464
- http://www.visa.com@33.32.323.22
- https://www.v-i-s-a.com
requête HTTP
- une URI (Unified Resource Identifier)
- quelques en-têtes / headers
- contraintes sur le contenu demandé
- informations contextuelles
- sous la forme clé: valeur
- un verbe HTTP décrivant l'action
- une ligne vide
- un corps servant à éventuellement envoyer des données
Note:
- dans la préhistoire le verbe est appelé méthode
requête HTTP de la vraie vie
GET / HTTP/1.1
Host: perdu.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
If-Modified-Since: Tue, 02 Mar 2010 18:52:21 GMT
If-None-Match: "cc-480d5dd98a340"
Cache-Control: max-age=0
useless data
Connaissez vous Burp Suite?
Note:
- Connection: keep-alive multiplexage de requête - envoyer plusieurs requêtes HTTP via la même connexion TCP (SPDY utilise ça)
- Accept-Encoding: gzip, deflate commpressions supportées par le navigateur
- le reste du cache
verbes HTTP
agissent sur une URI
- GET: récupérer une ressource ou une collection de ressources
- POST: créer un nouvelle ressource
- PUT: mettre à jour une ressource existante ou créer une nouvelle ressource à une URI donnée
- DELETE: supprimer une ressources données
- PATCH: mettre à jour partiellement une ressource existante
verbes HTTP
-
Must read: Please do not patch like an idiot
-
c.f. REST plus loin dans cette présentation
Note:
- La liste n'est pas exhaustive: HEAD, OPTIONS, TRACE, CONNECT
- tous idempotents sauf POST
- PATCH n'est pas dans la spec
réponse HTTP
composée
- d'un code HTTP
- de quelques en-têtes / headers
- informations sur le contenu servi
- sous la forme clé: valeur
- du contenu envoyé
réponse HTTP de la vraie vie
HTTP/1.1 304 Not Modified
Date: Fri, 20 Feb 2015 15:15:01 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=2, max=100
Etag: "cc-480d5dd98a340"
Vary: Accept-Encoding
<html>
<head><title>Vous Etes Perdu ?</title></head>
<body>
<h1>Perdu sur l'Internet ?</h1>
<h2>Pas de panique, on va vous aider</h2>
<strong>* <----- vous êtes ici </strong>
</body>
</html>
Note:
- Notez le header server qui donne déjà de l'information utile
- Etag, vary concerne le cache
les codes HTTP
-
1xx Informational
-
2xx Successful
- 200 OK
- 201 Created
- 204 No Content
-
3xx Redirections
- 301 Moved Permanently
- 302 Found
- 304 Not Modified
Note:
- 201 typique aprè un post
- 204 signifie un body de requête vide
- 301 vs 302 on change d'URI ou pas (definitif temporaire)
- 304 aucun besoin de recharger le contenu body vide
les codes d'erreur HTTP
-
4xx Client Error
- 400 Bad Request
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
- 405 Method Not Allowed
- 406 Not Acceptable
- 409 Conflict
- 415 Unsupported Media Type
- 418 I’m a teapot
les codes d'erreur HTTP
-
5xx Server Error
- 500 Internal Server Error
liste complète sur httpstatus.es
paramètres HTTP
deux types
- ceux passés via la query string de l'URL
- accessible via _$GET en PHP
- ceux passés via le corps de la requête
- accessible via _$POST en PHP
- tous les paramètres sont disponibles dans _$REQUEST en PHP
REpresentational State Transfer
REpresentational State Transfer
Must read:
- Haters gonna HATEOAS.
- L’architecture REST expliquée en 5 règles
- Architectural Styles and the Design of Network-based Software Architectures by Roy Thomas Fielding 2000
Note:
- Level 0 - HTTP comme protocole de transfert uniquement (transport only). Style RPC (SOAP, XML-RPC) on pourrait utiliser autre chose comme protocole
- Level 1 - Structure en Ressources individuelles, notion d'id sur les objet
- Level 2 - le Client utilise les verbes HTTP & les serveur les codes HTTP
- Level 3 - Hypermedia Controls = Content Negotiation + HATEOAS
- Level 3 - Content Negotiation -> sélectionner le format de représentation pour une ressource (json, xml, etc ..) le serveur tente de répondre au mieux autant que faire se peut.
- Level 3 - HATEOAS -> découvarbilité de l'API l'app est vue comme une machine à états
- on est loin du site web au sens CMS, pourautant ces services sont soumis au mêmes vulnérabilités
Exemple
https://gist.github.com/nealrs/28dbfe2c74dfdde26a30
document.addEventListener('DOMContentLoaded', function () {
q = "finger guns";
api_key = "crack me!";
api_url = "https://api.giphy.com/v1/gifs/random";
request = new XMLHttpRequest;
request.open('GET', api_url + '?api_key=' + api_key + '&tag='+q, true);
request.onload = function() {
if (request.status >= 200 && request.status < 400){
data = JSON.parse(request.responseText).data.image_url;
html_data = '<img src = "' + data + '" title="GIF via Giphy">';
document.getElementById("giphyme").innerHTML = html_data;
}
};
request.send();
});
HTTP est "stateless"
Note:
- Http est amnésique
- chaque requête est traitée comme une requête indépendante sans relation avec les précédentes
les cookies
- introduits par Netscape en 1994 pour fiabiliser l'implémentation du panier d'achat virtuel
- envoyés sous forme d'en tête HTTP par le serveur
Set-Cookie: name=value[; Max-Age=age][; expires=date] [; domain=domain_name][; path=some_path][; secure] [; HttpOnly]
- renvoyés inchangés par le client à chaque requête
Cookie: name=value
les cookies
- accessibles via _$COOKIE en PHP
- cloisonnés par domaine
- accessibles via les sous domaines
- blocable par l'option domain
- tracking cookie
- êtes vous en conformité avec la loi?
Note:
- https://www.owasp.org/index.php/HttpOnly -> pas de manipulation client side ANTI-XSS
- https://www.owasp.org/index.php/SecureFlag -> accessible en https uniquement
- sous domaine, google maps / google play / google.com
les sessions
données gérées côté serveur
- transimission de l'ID de session uniquement
Cookie: PHPSESSID=hr0ms75gs6f7vlph0hhct2bjj3
- accessibles via _$SESSION en PHP
local storage
- un peu comme les cookies MAIS
- données gérées coté client uniquement
- transmise par js via api ou via le cookie
- 5MB / domaine contre 4096bytes pour le cookie
- supprimable uniquement via js
header, cookie, body, query string, script ...