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.


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.

  • 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

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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.