0

Following on from the thread Is Safari on iOS 6 caching $.ajax results?

If io6 safari is caching the results from non unique ajax calls then it must also be caching the call itself. Would this then mean it is caching usernames and passwords in a login situation thereby posing a security risk?

Community
  • 1
  • 1
PrimeLens
  • 2,547
  • 4
  • 23
  • 28

1 Answers1

1

Short version: If you're sending usernames and passwords over the wire in plaintext, you've already opened a huge security hole.

Long version: Browsers will cache based on URI, so if you're sending user/pass as GET variables, then yes it will cache and yes it is a security risk. However, even if the browser didn't cache this, you're still doing something wrong. A third party need only look at the HTTP header to see what the user/pass is.

If you are sending this as POST, it is a bit harder to find the username/password. The browser will not cache the request as the URL is always the same. However, it is still possible to read the content of the request and find the user/pass.

To be the most secure, use HTTPS and pass the values via POST. The entire HTTP request is encrypted, including the headers. However, the browser will still cache the URL, so using GET variables is still a bad idea.

Example from the jQuery documentation on using POST with ajax:

$.ajax({
  type: "POST",
  url: "some.php",
  data: { name: "John", location: "Boston" }
}).done(function( msg ) {
  alert( "Data Saved: " + msg );
});
monitorjbl
  • 4,280
  • 3
  • 36
  • 45
  • sending as $.ajax, other thread says to add dateTime to make call unique. If call is not unique how does ios6 safari know the difference unless it is also caching the call? – PrimeLens Sep 22 '12 at 20:16
  • AJAX is not an HTTP method, it is a browser technology for asynchronously sending HTTP data. You can specify the method in jQuery with the type option. EDIT: I moved this to the answer. – monitorjbl Sep 22 '12 at 20:18
  • as per thread I linked to, safari iOS6 is caching the ajax call results because it is recognizing that the call is repeated. Therefore it must be caching the call itself in order to know the difference. Thats what I meant in my original post. – PrimeLens Sep 22 '12 at 20:25
  • Ah...I didn't read that. So that means that Safari is breaking the HTTP caching spec, which *is* a serious security risk. There's actually a very visible Ars Technica article on this, so I would hope that Apple fixes this in the future. It's seriously bad form to violate the HTTP spec, that's what got Internet Explorer such a terrible reputation. – monitorjbl Sep 22 '12 at 20:44