mod_secdownload option to include url GET parameters in md5
I am using lighttpd secure_download to restrict access to multimedia files (images and videos) to registered members to a website. However I needed to include the get parameters in the md5 hash to protect mod_flv_streaming type of URLs (http://someserver.com/some_video.flv?start=1234).
I wrote some code to support this. The string to be hashed is:
where parameters-string is for exemple "start=1234", or "start=1234&id=4321"
The following option can be used in lighttpd config file to activate this behaviour (which is disabled by default):
secdownload.md5-params = "enable"
An exemple of a generated URL:
If a user try to alter the parameters (ie: start=0&end=120) or to remove them, mod_secdownload will return a 403 error.
I included a diff file to that issue report and I would greatly appreciate I you could consider using this patch in a future release.
secdownload.path-segments = <number>
include only given number of path segments in hash digest calculation
secdownload.hash-querystr = "enable" | "disable"
include the query string in the hash digest calculation
#4 Updated by stbuehler over 5 years ago
- Target version set to 1.4.x
- Missing in 1.5.x set to No
1.4.x is sort of "stable", so feature requests are not a priority. And if the target version isn't set i don't see them in the roadmap, so they get lost pretty fast :)
The patch itself looks fine apart from one detail: imho the "?" should be part of the md5 too (con->uri.query starts after the "?").
- Subject changed from mod_secure_download option to include url GET parameters in md5 to mod_secdownload option to include url GET parameters in md5
- Status changed from New to Need Feedback
- Priority changed from Normal to Low
Is this feature request still desirable?
In the intervening year, additional algorithms have been added to mod_secdownload which are more tamper resistant than MD5: HMAC-SHA1 and HMAC-SHA256
Even if using MD5, arbitrary validation could be accomplished using a FastCGI authorizer in lieu of mod_secdownload, allowing the creation of the keys to be collocated with the code which validates the keys, instead of trying to extend mod_secdownload in a variety of ways.
Also available in: Atom