2010-01-07 4 views
12

La falsification de requête intersites est-elle possible contre un service RESTful sans état? Je ne parle pas de pseudo-REST où le serveur se souvient que vous êtes connecté via un cookie. Je parle de REST pur sans application-état-sur-le-serveur sans cookies. J'utilise SSL et l'authentification de base. J'utilise SSL et l'authentification de base. Pour chaque requête, cet en-tête Authorization doit être présent. Il n'y a pas de "session" au sens du JSP, bien qu'il existe une sorte de session au niveau SSL. Supposons que je visualise la page Web légitime qui fait des requêtes Ajax, et d'une façon ou d'une autre je vais sur une page différente dans le même onglet ou dans un onglet différent, et cette page fait la même requête Ajax. (Je suppose qu'il n'y a pas de code malveillant sur la page web légitime, c'est complètement différent et tout est possible dans ce cas.)REST et CSRF (Cross-Site Request Forgery)

Lorsque la deuxième page fait la requête Ajax, le navigateur mettra-t-il le même En-tête d'autorisation? c'est-à-dire que le navigateur dira "Oh, vous voulez y aller encore? Hey, il m'arrive d'avoir toujours la clé!"?

De même, le script malveillant ne peut-il pas faire la requête xhr, puis, dans le rappel, prendre la requête à partir des ioargs, obtenir l'en-tête Authorization et un-Base64 le nom et le mot de passe?

Répondre

4

Avis de non-responsabilité: Je ne suis pas un expert en sécurité.

L'utilisation de HTTP Basic Auth n'empêche pas les attaques CSRF via les requêtes GET. Par exemple. Quelqu'un d'autre peut inclure une balise img dans sa page HTML qui fait un get sur un URI bien connu, et votre navigateur enverra heureusement les informations authentiques de base. Si l'opération GET est "sûre" (ce qui est la règle n ° 1 pour tout ce qui prétend être RESTful), cela ne créera pas de problème (au-delà de la bande passante gaspillée).

Ajax n'est pas un problème à cause de la politique de même origine. L'inclusion d'un jeton généré par le serveur dans le code HTML que vous générez et la validation de sa présence dans les demandes de soumission de formulaire vous protègeront de toute autre personne en incluant simplement un formulaire "étranger" dans ses pages. Vous pouvez limiter cela aux types de contenu générés par les navigateurs. pas besoin de le faire pour les demandes XHR.

+0

Les IFrames tournent autour de la même origine. Serait-ce possible: hisData = une sorte de iframe XHRGet (csrf); myURL = 'http: //mon.site/grab? Data =' + urlEncode (hisData); myPic.innerHTML = ' ";? En supposant que csrf est une URL qui obtient des données sensibles, et un GET sur my.site/grab enregistre ces données que nous mettons dans la requête –

+0

Le navigateur ne vérifiera-t-il pas cela? – Nikhil