Is it possible to configure the FlexPaper reader to decrypt password-protected PDFs or SWFs?
Here is the use-case:
User uploads a PDF.
My server would then convert the PDF to SWF via pdf2swf.
Then somehow encrypt the SWF with a password (not sure best way to do this).
Then the FlexPaper would be able to decrypt the SWF and display it.
What I am trying to avoid is the caching of readable SWF in the browser's cache.
Any ideas on the best way to achieve this?
I know, even with this it will not be a fully secure solution, but certainly helps.
Note: I am running this on Linux and OS X and using Rails.
Answers from questions asked in the responses:
Do you need it on the wire?
No, I don't think so, the application will be only accessed via SSL
Do you need the files to be stored securely on your hard drive?
Ideally yes, we will keep them encrypted on the server -- but not critical
What exactly are you trying to prevent by encrypting them?
I want users of the application only to be able to view the documents from the FlexPaper reader on the website. I do not want users to be able to download a readable document to their machine.
Thanks!
Jonathan
What I am trying to avoid is the caching of readable swf in the browser's cache.
I'm not sure if using a password will help at all. If the SWF is encrypted it may likely be stored in the cache encrypted. I think this post on how to prevent caching is probably what you want.
But in case not, I'll answer some of the encryption questions below.
pdf2swf supports a -P (or --password) option that allows you to decrypt an encrypted PDF, which implies you need a password fairly early in that process.
If you want to encrypt the SWF, you should check out the as3crypto libraries for the Flex side and some ruby crypto libraries for the server side.
I have a blog post entitled, "Why Obfuscate, Encrypt those SWFs! that talks about how you can encrypt a SWF that is then decrypted via a SWFLoader that I hope is useful to you. The same concepts apply here:
Encrypt the SWF (after it's been converted from PDF)
Use a modified SWFLoader (or URLLoader) to decrypt the SWF
Use the decrypted SWF just like you would a regular one
But, a few questions:
Where do you need security? Do you need it on the wire? Do you need the files to be stored securely on your hard drive? What exactly are you trying to prevent by encrypting them? The answers to these questions will largely determine the best approach to take.
Related
I have a cordova application which downloads a zip file as blob from azure. Since I am very new to azure, I would like to know that is it okay security wise to access azure blob with SAS url from the cordova application ?
My point is that I would need to append the shared access signature (SAS) token to the blob url, something like below.
https://myazureportal.container.blobs/myblob?MY_SAS
This way my javascript code will have SAS hard-coded. What is the correct approach since I would prefer to access blob using javascript only and preferably without writing any server side code if possible ?
if I use SAS inside javascript files of my cordova application, is it a security flaw ? If so, any approach to implement the same using purely javascript only ?
Things I tried:
Created a back-end WEB-API service in ASP.NET Core and this way, I would be able to download the blob file but I am looking for is a pure javascript approach.
Apart from the point mentioned by Eric about code being decompiled, there are a few other things you would need to worry about.
If you are embedding the SAS URL in your application, you will have to make them long-lived i.e. with an expiry date far out in future. That's a security risk and is against best practices.
A shared access signature is created using an account key and becomes invalid the moment you regenerate your account key. If you're embedding SAS URL in your application and have to regenerate your account key for any reason, your SAS URL becomes essentially useless.
You can learn more about the best practices for SAS Token here: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview#best-practices-when-using-sas.
Yes it is a security flaw as your app can be decompiled and your code inspected. If you want to keep this approach, at least have a login connected to a back-end that sends the SAS back to your front-end.
Ideally you would do everything in the back-end and return the blob to your front-end.
We have a file upload system that PGP encrypts data in the browser before it is sent to our servers. The files are then viewed by us in a specially designed local program. We decided this was the safest way to store that data. One downside to this we find in our own testing is that we can really upload anything at all, random strings etc., because we can't verify what that data is once encrypted without keeping our private keys on a server that is connected to the internet. It seems to me that this is a pretty big potential flaw, though I can't put my finger on exactly what could be done with it. Aside from sanitizing and checking data before viewing it, what can we do to mitigate the issue? Should we take another route entirely for protecting the data?
Edit: We realized the public key used to encrypt could simply be changed by an attacker and they'd have access to all files encrypted from that point. The current suggestion is to encrypt using hashed user password+salt generated at login time and then storing that key on another server (protected by master password) so that we too can view them. The issue of changing keys seems to be mitigated by this (though keys could plausibly be intercepted while being sent to the secure storage server).
I know there are many similar questions on the internet but none of them could solve my doubt. So pardon me. About my project. I have a java file or program that takes a string , encrypts it and then returns the encrypted string to me.
I want to include or keep this java file (.jar file) on the webpage or the client-side. Now I know that we can upload this java program on server side and then easily communicate with it instead of calling keeping it on client-side which most people consider a bad practice.
But my purpose of keeping this jar file on the client side is that JavaScript code for encryption can be easily seen if we inspect element, so compared to it .jar file is more secure and one cannot see underlying encryption code and also if in case the there is network loss then instead of typing the entire string again and getting it encrypted again from the server, I want to save that string in such situation, get it encrypted from the jar file on the client-side so that once network problem is solved I don't need to retype whole message again and then I can directly send the message or the string to the other end or to other user on the network.
So for this I need help regarding how can I store my .jar file on webpage or client-side and then how to call methods from the .jar file using JavaScript. I know applets are deprecated, chrome does not support java. I have also seen some examples on internet like https://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html but Its not working properly for me.
So I am in search of some ideal method by which I can first of all include or upload .jar file on client-side and then a method by which I can call java methods from .jar file using JavaScript. Please help... My earnest request...!
JavaScript code for encryption can be easily seen if we inspect element
I'm assuming you mean embedded Javascript here. Because you can refer to an external JS files which are located on the web server, not the client machine.
The browser may cache your script file somewhere locally but if one were bothered enough to dig it up, he might as well decompile your jar file which is much more easier.
Java can easily be decompiled. A jar file on the client will not be more secure than client-side JavaScript.
An encryption method that is compromised by looking at its code is not secure.
You seem to have many misconceptions... here are some facts for you to consider:
A JAR file (as either an application, WebStart or applet) running on client-side is NOT secure. If it runs on my computer, I can do anything I want. I can download the JAR file and decompile it. It's no better than JavaScript in this regard, it just takes slightly more effort and knowledge.
To protect data between client and server, you can simply use HTTPS and POST the data from web page to your server.
If client is encrypting data to you, there should be nothing to hide about the encryption process. The client generates a session key to encrypt the data, then wrap that session key by your server's public key. Then client send both encrypted data and wrapped session key to your server. Read more about Public Key Infrastructure (PKI): https://en.wikipedia.org/wiki/Public_key_infrastructure
By default a Java applet/WebStart is not granted access to disk. You must sign it to write data to disk, and user/security policies can still deny granting those access rights. (Applet - Unable to write file)
As you are aware of it, applet/WebStart is dying because of browsers rejecting plugins. There's Web Cryptography API (it's not mature, and there's no hardware support), you can try that instead. https://www.w3.org/TR/WebCryptoAPI/
In this use case, the server send an encypted blob to the browser and the the javascript on the browser subsequently requests the decryption key from the server and decrypts the blob to usable content.
Is there a way to protect this key on the browser from an attack by a bookmarklet or browser plugin or the user stepping through the javascript debugger on browser? Or atleast make it a slightly harder problem for the attacker.
Edit : the context of the problem is HTML Video DRM as specified in EME specifications. There is a ClearKey api that is part of this standard and does nor require closed source plugin from WideVine or FairPlay etc. But as multiple responses have pointed out, ClearKey cannot be protected. (which unfortunately means using propritory DRM plugins).
You can not guarantee the security of any data once it reaches the client.
There is just no way to do this. Once the client receives this, especially if they also receive the decryption key, they have full access to all the secrets within.
On a very simple scale, they can just drop some breakpoint or put some prints in the javascript console. If they want to get more advanced they can use tools like wireshark to see the data as it comes over the wire.
Now if you want to send them encrypted data that doesn't get decrypted, and it is strongly encrypted, then its not as bad. But if you're never going to decrypt it on their side, then what are you even sending it for?
Agree that it can't be done. You could do it with asymmetric encryption. But I would go back to why you're doing it - if the connection were SSL encrypted, there is no reason to do it.
I'm currently developing an application in HTML+JS based almost entirely in ajax connections (using the jQuery.ajax() call to ease the process).
I was thinking about the best practice to make secure calls without using HTTPS (at least at this time. I can't afford paying for a certificate right now).
At this point, the only thing that concerns me is the registration and login steps. Maybe the login is a bit easier. I thought of sending the username and a timestamp, and then encrypt them using the user's password. So, by doing this, I wouldn't be sending any password (keeping as a secret like in OAuth). The server should check the user, decrypt using the password and pairing the recieved timestamp with the decrypted result. The server should keep the nonce-like number into a database (to avoid repetition attacks) and then give back to the user another unique id (encrypted with the user's password). At that point the user should start using that key to encrypt all his information (and probably another nonce) and send it to the server. Please correct me if you find any mistake or leak.
The very big problem to me is the registration. I can't encrypt with a regular password the information, because if I do that in the javascript, any could know the password. If I serve temporary generated passwords to encrypt and I send it from the server to the client, any sniffer could get it and use to decrypt the info.
I know HTTPS could save my life at this point (and maybe that's the only solution), but at this point I'm not able to use it.
Is there any other solution, or should I wait until I can use HTTPS? Bear in mind that if I could skip the wait, it would be better. Thanks mates!
Short answer: You can't do it without HTTPS
Longer answer: If you try to do it without HTTPS, you will find yourself trying to reproduce everything that HTTPS was designed to do. You could reach at some point, but it is unrealistic to believe that you will succeed in implementing even the 1% that HTTPS offers. The only benefit you will have would be an obscure security mechanism (security through obscurity), which may be OK for not critical systems, but would fail miserably in a real critical situation.
You could create your own certificate you know and then work with Ajax the same way as with regular HTTP calls. The only drawback is that the users will get a warning message.
Using an SSL Certificate is the only way really, if you encrypt it in javascript anyone can read the code and decrypt it.
http://www.startssl.com/
Generate a public/private key pair on the server, along with a randomly-generated salt.
Attach the key pair and salt to the user session object.
Send the public key and the salt to the client-side code.
Use the public key and salt to encrypt the AJAX requests.
This would not be a trivial task. You'll probably find that it's cheaper and more effective to just buy a certificate.
EDIT: This also means that all the regular HTTP traffic (HTML, images, CSS, etc) is sent in the clear. That could be a problem, since it might allow an eavesdropper to indirectly figure out what the user is doing.
I think you should have a look at :
http://assl.sullof.com/assl/
Here is the description of the project :
aSSL is a library distributed under MIT License thats implements a technology similar to SSL without HTTPS.
aSSL enables the client to negotiate a secret random 128-bit key with the server using the RSA algorithm. Once the connection has been established, the data will be sent and received using AES algorithm.
aSSL is composed of some Javascript files and a server side component. Because I have recently changed the negotiation algoritm from RC4 to RSA, only a pure Javascript (ASP) server component is currently available. I will do a porting for the main web languages (PHP, Java, Perl, Python, TKL, etc.) as soon as possible once the library has passed the beta phase.