开发者

Encrypting URL of redirect to an outside website

I am developing a web application that will redirect users to an outside web application. I would like to encrypt the redirect url so the users can not directly modify the url. The outside vendor would like to use triple DES. Here is my questions:

  1. I assume that the developers of the outside web application and I will have to exchange some sort of "Secret key" so we can decrypt and encrypt the url, is that a correct?

  2. Is this "Secret Key" some sort of file or some se开发者_StackOverflowquence of characters we can perhaps initially exchange via email?

  3. Does it matter that I am writing my web app in Java and the outside vendor is writing their web app in .NET?


Sounds like you need to sign the request parameters, rather than encrypt them. You could try something like this;

1) Create a string of the data you want to protect with a digital signature, for example if your URL is;

http://www.example.com/doCourse?userid=123&courseid=abc

and you want to protect the userid and courseid parameters you create a string;

courseid=abc&userid=123

Note that in cases such as these it is normal to create the string with the parameters in alphabetical order.

2) Use a Message Authentication Code with a cryptographic hash function such as SHA-1 to generate a hash of your string.

Do this with;

Key key = ..... //You need to agree a key with the other party.
String string = ..... //The data you want to sign eg "courseid=abc&userid=123"
Mac mac = Mac.getInstance("HMAC-SHA1");
mac.init(key);
byte[] result = mac.doFinal(string.getBytes("UTF-8");

The MAC basically uses a secret key (which you agree with the other party in advance) to generate a hash of the data.

3) Base64 encode, then URLEncode the result and include it on the redirect as a parameter (call it something like 'signature').

4) The other party performs the same actions as you, they generate the string, use a MAC to create a hash, base64 encode and URL encode. Next, they compare the signature on the request with the one they have generated. If it is the same then the parameters have not been tampered with. If the hash is different then the user must have modified them.

You may want to also include a cryptographic nonce with the request to prevent replay attacks. If you use a nonce, make sure you include the nonce parameter and value in the string you use to generate the signature (ensures the user can't tamper with the nonce).

Advantages over encryption

  • URLs are not obscufated at the expense of supporting this in the web apps.
  • Security can be achieved with a simple filter in front of the web app that just checks signatures.
  • You can tell whether the user has modified the data, which cannot be guaranteed just by encryption. With TDES the user may alter the ciphertext and accidently create a valid but different plaintext.


You're correct in that you will need to exchange some key and that it can be exchanged by email or any other method you trust, and that its just a sequence of characters. It should not matter what programming languages you're using as long as you're using the same encryption algorithm.

What you're describing sounds like it might not be particularly secure, but perhaps you're only interested in guarding against very casual attacks? If you want better security over who can reach the end URL, you need to provide some form of authentication on the server that provides that URL rather than relying on users not knowing the URL -- discovering where my browser has taken me to is quite trivial. If normal user authentication is not appropriate for your application you might consider including temporal authentication data in your query (as long as the server is able to verify it, of course).


Answers:

1 - yes, you'll exchange some key. Since he's asking you this encryption, I'd ask him to provide the key;

2 - yes, he can provide you the key anyway you feel it's secure, be it email or any other means;

3 - It doesn't matter which languages you are using.

For what I could understand, users on your system will click in a button and be sent to another site. This site will have a address and some parameters, that's right? like http://some.address.com/some.page&param1=x&param2=2

So you would encrypt the addressto be like http://some.address.com/2183u49823423hj23h, that's it?

So, be carefull to encrypt just the parameters, not the whole address (or your system won't be able do know where to go).

And take a look, or talk with the other site developer, if you should encode the encrypt information in some way. Sometinmes encryption generates lots of characters, some that might be hard / boring to be used in internet and site's address. Ask him about encoding in base64, for example.


1) Yes. You will need to supply the key which encodes/decodes. 2) It can be a sequence of characters. You can actually use .NET to test the strength in a test app and generate the key as a string that way. 3) Yes. I have written an interface where Triple-Des encryption from .NET was decrypted in Java. The algorithm for Triple-Des is the same between languages so as long as the keys are the same decryption/encryption will behave the same.

You would also want to create an Initialization Vector that can be shared as well.


From my point of view you are using the wrong approach:

Why don't you simply set-up a Servlet that responses with an HTTP 302 and the URL you want to redirect to?

No user would be able to change the URL as it is part of the servlet you are using.

If you want to change the url later you could also load the URL from Java properties so that the server admin would be able to change the URL.

Keep it simple and stupid and also secure without any encryption.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜