Skip to main content

How do you protect your web server resources? Use signed URLs


Illustration:
Say, you have public URL to access abc.mp4. http://mydomain.com/abc.mp4. And it is made available under pay per download subscription. This is a public URL and anybody can access, but there is a business model around it, which is ‘Pay per download’. This is a revenue leakage if everyone is able to download the asset. How should you make it available for download, but only for one download? You want this URL to be invalid after one usage.
Answer: Use signed URLs.

Signed URLs are usually short lived URLs. Servers are designed to deny access after the expiry of such URLs. It is also possible to specify additional information along with Signed URL, usually will be additional information is determined by the server in focus.

How does it work?
Continuing from the illustration, I define a policy. Policy is nothing but information that your client application will be able to communicate with server application so that server can decide the nature of access to the asset. This can be as simple as a JSON formatted text.

For the illustration, call Client app as C and server app as S. C creates a policy with information, say, ‘Allow_access_to_abc.mp4_18_00_hrs_only_once’. C will hash (creates digest) with SHA-1 algorithm which results in unique digest, say, 123kffsfsfg#$.  C signs the hash generated with the private key and say, the signature generated is ‘uuffaffgfgf’.

Note: Hashing on any given string, results in unique fingerprint, using which you cannot get back the original string. However, the algorithm generates exactly the same unique fingerprint for that string. This way, one can be sure that no one has tampered with information in transit.

Next, C does base64 encoding on the policy, say it results in ‘AB133444CDFDAAABC37122’. After this, C will generate a signed URL, 

http://mydomain.com/abc.mp4?policy= Allow_access_to_abc.mp4_18_00_hrs_only_once&hash=123kffsfsfg#$&signature=uuffaffgfgf

At the server side, S receives the URL, verifies the signature using the public key. S is assured that it is C who signed the hash. Then, S base64 decodes the policy and generates the hash, which in this case will result 123kffsfsfg#$. S matches the generated hash with the hash value sent as parameter in signed URL. Match is positive, S understands that no one has tampered the policy in the transit and interprets the policy and decides the nature of access. S expires the URL after some time and denies repeated unauthorized access.

Comments

Post a Comment

Thanks for your comments.

Popular posts from this blog

Key to adopt open source product

Friends, I am working on business solution implementation on open source product called Kaltura. Kaltura is a media management solution and has loads of features that compel any business to take a peek into it. More-over this is the only complete end-to-end open source software available to handle digital assets. But it comes with its own head ache. Considering its open source, its understandable. I feel, handling these would ensure you the success in your open source product implementation. 1. In my opinion, before adopting any open source software, build the capability to deal with the inconsistency bundled in the open source software. 2. I would avoid involving external consultants for 2 reasons.      a. I am not sure, they would bring necessary expertise on to table      b. I fear that there would be little ownership, they will not see big picture of my business (neither I am interested to share it all) 3. Alternative to that is to build the tea...
1 comment
Read more

Secure your application on cloud

Handling sensitive data Define sensitive data for your application. Classify as sensitive data and confidential data. Sensitive data is something like password, credit card account number, something that you should not compromise at all. Confidential data could be your customer’s health record, something that requires your permission before its usage. So, you need to define sensitive data in the context of your application. There are many ways to protect the sensitive data in transit; the easiest way is to use SSL. This is nothing different than handling sensitive data in any traditional application.   However, make sure you apply this rule while designing your application for cloud deployment. Alternatively, you can encrypt the sensitive data and transport. Be noted that any kind of protection you design, will have implications on performance. However this is ignorable considering the nature of sensitive data. If you just want to protect your data from being tampered du...
Post a Comment
Read more

Object orientation and Service orientation

Object orientation is all about modeling the real world information mainly through encapsulation, abstraction, polymorphism, containment, inheritance and so on. In simple words, an object contains the data structures and methods to change the content state. A typical OO run-time manages the life cycle of objects. You can create as many objects as required as long as the run-time does not over run its memory. Service orientation requires you to encapsulate a process. The operations of a services are interaction points with the particular process. Data structures are the arguments for these operations. Service run-time shall validate the correctness of the process. Service can have multiple invocation instances, not multiple instances of service itself. Example: TrainTicketBookingService involves a process. - Check the train timings //  interaction point - Check the seat availability // interaction point - Issue ticket // interaction point There could be many ticket...
Post a Comment
Read more