1

Would implementing signed URL's be an effective security measure to prevent URL tampering and poisoning on public facing resources accessed via a GET request.

e.g. http://www.domain.com/:url_to_resource/:hash http://cdn.domain.com/:url_to_resource.js?:hash

Hash in my case would correspond to my cache key for the resource.

Any feedback, improvements, or critiques would be greatly appreciated.

Null
  • 187
  • 1
  • 11

2 Answers2

1

If it's being altered coming from the client, then we'd also need a mechanism for client certificates to have trust. To avoid alterations on the connection coming from the server, SSL would already cover this and more. Really, I fail to see what this would offer over the capabilities of SSL unless you are simply looking for a lighter weight way to protect links without having to use a full SSL connection.

This also seems like it would be very open to replay attacks unless some kind of IV was provided since if the server ever displayed a URL to an attacker, that URL could then be copied, with signature, to any future user. This would be particularly devastating on a site that allowed links to be made by users, though perhaps those links could be left untrusted and unsigned.

AJ Henderson
  • 42,081
  • 5
  • 65
  • 112
  • How would this effect your answer:

    When a user first hits the page, you create a HTTP only, secure Cookie HMAC(SessionID, SharedSecret, scrypt(Password), expires). Cookie is associated with a DB table Session(SessionID, data, HMAC, signature, expires). All data is encrypted on the client so the server can never read data. (Plausible Deniability).

     – Null Aug 12 '13 at 13:33
  • @4e494c - I'm not sure I follow your meaning or intent from that comment. Is "you" server? If so, what is data and what does signature refer to? There isn't enough context of how you intend to use these values for me to make sense of it. – AJ Henderson Aug 12 '13 at 13:39
  • Correct, "you" refers to the server. SharedSecret refers to a unique shared secret between the server & user's cookie. Session signature is basically just a normalized representation of the hash signature and expires is simply a expiry date in numerical format. – Null Aug 12 '13 at 13:49
  • @4e494c - ok, how is that supposed to be helpful with the case of signing the links and in which direction? I'm still not understanding how it would be used in context of the original situation. – AJ Henderson Aug 12 '13 at 13:52
  • the signature && || HMAC will contain the JS file hash. Process flow: User -> Site -> Cookie/Session -> Site -> JS (with signed url). Appologies for confusion, i was trying to mulitask a few to many questions. – Null Aug 12 '13 at 14:02
  • @4e494c - so are you just trying to make sure a link being returned by the client is the same as the server provided to it? If the HMAC and signature both originate or are known on the server, then what are you trying to accomplish. I'm really lost at this point. – AJ Henderson Aug 12 '13 at 14:19
  • Sorry long day. For my use case Im just looking for a way to validate that a javascript file sent from the server is authentic and unaltered when it reaches the user. Otherise client side crypto is pretty useless, and easily exploitable if I cant validate the files signature.

    Although my original questions was that URL signing could be used to protect against allot of URI exploits so I attempted to generalize the question to make the question more useful to others.

    e.g. /index.php?:hash&file=../../../etc/password

     – Null Aug 12 '13 at 14:30
  • @4e494c - in that case, simply a signature based on the server certificate would be sufficient to verify the JS file, but the problem would be letting the browser know that it should expect the JS file to be signed. This is actually the same fundamental problem that most of the recent SSL attacks exploit by side stepping the process by making the browser not expect signed or encrypted content. I don't see any real gain over simply using SSL for the connection, since without that, the flag to set the browser to check could be stripped, just like SSLStrip does. – AJ Henderson Aug 12 '13 at 15:14
  • would developing a browser addon thats that validates/verifies the JS file be a workable solution to this issue? – Null Aug 14 '13 at 14:14
  • @Null - Unless every JS file on the Internet is signed, there is no way for the browser to know when it first visits a site that the JS file should provide a signature. Every attempt as establishing an SSL connection by the server can be stripped off and sent to the user as a non-protected page. – AJ Henderson Aug 14 '13 at 14:49
  • I dont think every JS would need it. It could be opt in by declaring a CORS type config on the same server and apply same origin policies. This could then be tied back the the signed url concept i asked about above. SSLStrip is a concern I havent given much thought. Thanks for the direction. – Null Aug 14 '13 at 15:47
  • @Null - but how do you ensure that that information reaches the client. The point of such a signature is to prevent a mitm attack, but a mitm could simply not set the config. You would never talk to the correct server, so your browser would never know to expect it. – AJ Henderson Aug 14 '13 at 16:21
0

Might help if tampering is done in-transit (proxy, MITM), but won't help if the tampering is done at the server (SQL or PHP injection, or replacing files).

Given that a very large percentage of the web is generated dynamically, the hash would have to be calculated by the server as it serves the page... I think this would require an overhaul of both the server and browser end as one request would need to return both the page and it's hash, otherwise by the time the second request is sent to get the hash, the page may have legitimately changed.

All it really proves is that the page is the page that the server sent you and we already have HTTPS for that.

Rod MacPherson
  • 1,117
  • 7
  • 11
  • Thanks Rod, appreciate your input. My original design was to allow secure client side JS transmission from a trusted SERVER over SSL/TLS, this would be a relatively static asset, the intended use case is client side crypto. Do you see any obvious gotchas, besides the usual client side crypto isnt secure. – Null Aug 12 '13 at 12:38
  • If you are using it to prove the url hasn't been altered then you are wasting your time a bit as https proves that. What do you mean by client side crypto? Are you talking about authentication? – Ross Dargan Aug 12 '13 at 12:45
  • With the various attacks on SSL/TLS presented at BlackHat 2013, my concerns is SSL/TLS aka HTTPS is already weakend, not neccessarily broken. So the HTTPS proof isnt entirely fool proof. e.g. If an entity was to intercept HTTPS traffic (PRISM) I could theoretically alter the response (file) at a network level or even easier remap CDN url to a fake server and send malicious assets.

    My intended use case is to provide inbrowser crypto to encrypt session data on the client using a shared key, and only deal with encrypted data on the server.

     – Null Aug 12 '13 at 13:04
  • If a malicious party can change the content of the page, then surely they can point you to any asset they want (and disable any javascript based validation you implement) – Ross Dargan Aug 12 '13 at 13:17
  • @RossDargan Correct, but if I could use this hash/signature the server sent to test this for validity, I could then reject the session, refresh the page, warn the user and try regenerate. Or am I missing something? – Null Aug 12 '13 at 13:22
  • if someone was being malicious the chances are they would force you to get data from a different server with no checks. If they wanted to get it from your server then they could likely do a MITM attack where they force you to do a get from there server, which does a get request to your server to get a valid hash, they then get that data and return it to you. If they have broken ssl they have your session cookies and so can impersonate you. – Ross Dargan Aug 12 '13 at 13:27
  • @RossDargan, how would this effect your answer.

    When a user first hits the page, you create a HTTP only, secure Cookie HMAC(SessionID, SharedSecret, scrypt(Password), expires). Cookie is associated with a DB table Session(SessionID, data, HMAC, signature, expires). All data is encrypted on the client so the server can never read data. SO it would be useless to an attacker?

     – Null Aug 12 '13 at 13:36
  • Its getting difficult to understand what you are actually protecting. If you are worried that ssl is broken, then making the cookie http only doesn't matter - a MITM attack would scoop the cookie up and could me used by the attacker to decrypt all required info. – Ross Dargan Aug 12 '13 at 14:09
  • @RossDargan, I will give my question some thought and rephrase. – Null Aug 12 '13 at 14:15