4

I am developing a fat client page based on Javascript that will allow users to carry out tasks outwith another web client application (Oracle Siebel).

The way the web page will be called from the browser will be by a simple window.open() call.

When this happens a URL will be passed which contains some parameters at the end which will change the functionality of the fat client page depending on what value they have.

e.g

userlevel=1 //normal user

userlevel=2 //advanced user

In an example full URL would be like so

www.mypage.com/index.htm?id=25215125%userlevel=2%context=full

However a user who wants to change their access only need to figure out that if they change their user level then they can change their access rights on this fat client page.

Yes, I know this is risky and before you ask why I am not using a server supported thin client with controls that cannot be altered by the user. I simply have to do it this way!

This system will be in a "trusted" environment and this users will have at best average IT skills.

So all I need to do is figure out a way to obfuscate/ scramble the URL parameters (if possible) and then decipher them at the fat client.

e.g.

www.mypage.com/index.htm?1sdf908ga90-821098650f8asdg098g0a98

I tested it out on the browser and no complaints so far so I guess I just need to develop a piece of logic to decipher it.

e.g. I could use MD5?

Any examples or ideas?

Thanks

tomaytotomato
  • 3,788
  • 16
  • 64
  • 119
  • Better for security.stackexchange.com, if this meets their FAQ. – djechlin Mar 12 '13 at 13:47
  • 4
    If the client needs to undo the hash, than anyone can undo the hash. Security on the client is a joke. All of the security should be done on the server. VALIDATE, stuff that only an admin should see should not be there on the page in the first place. – epascarello Mar 12 '13 at 13:48
  • Beware hash collisions. MD5 is a hash, not an encryption. – Dan Pichelman Mar 12 '13 at 13:50
  • Its not really security its more restriction in that unexperienced users dont mess up stuff – tomaytotomato Mar 12 '13 at 13:50
  • @DanPichelman ; I guess hashing a URL parameter string would be enough of a countermeasure against a curious user? – tomaytotomato Mar 12 '13 at 13:52
  • Then just use a lucky charms decoder ring. If the third digit is a 6 it's an advanced user, otherwise a basic user. – djechlin Mar 12 '13 at 13:52
  • @djechlin ; a link please that sounds interesting :) – tomaytotomato Mar 12 '13 at 13:53
  • As long as 2 individual parameter strings don't hash to the same value, then a hash would probably be sufficient. – Dan Pichelman Mar 12 '13 at 13:53
  • @epascarello ; I know this is not the best way but this is the corporate world of Software dev . If it costs more then its not done! – tomaytotomato Mar 12 '13 at 13:54
  • 1
    He said he was aware that this would still be insecure, he's just looking for basic obfuscation...@loosebruce I'm a little confused about what code you *can* change. You said you can't modify the server code so how would you decipher the URL? Anyway I'm obviously just misunderstanding...MD5 would probably be your best bet since it's a one-way hash, you just hash the string you want to compare it with also and see if they match. – Matt Browne Mar 12 '13 at 13:56
  • @MattB. I will send a requirement spec for the server side team to develop functionality to call the url with an agreed hashing pattern that my client app can then decipher – tomaytotomato Mar 12 '13 at 14:00
  • 3
    @loosebruce why not just send a spec for the server side team to implement authentication securely? – djechlin Mar 12 '13 at 14:01
  • What happens when you have one random user who happens to be working on a side coding project at home and looks at the URL and is like "I wonder if I can decode that." You can cry corporate all you want but if you are doing something easily breakable it damn well better be documented as a risk business needs to explicitly sign off, then be prepared to explain why it's too expensive to implement something securely beyond "I don't know how." – djechlin Mar 12 '13 at 14:05
  • I don't know why this got downvoted :( – tomaytotomato Mar 13 '13 at 11:32

2 Answers2

3

Try Base64 encoding it. https://stackoverflow.com/a/4699739/1088652

That'll shorten it and obfuscate it, so that users can't just throw values in the URL.

Community
  • 1
  • 1
Fred
  • 1,344
  • 1
  • 11
  • 16
  • 1
    Concatenate all the parameters into a single pipe delimited string, then Base64 that string. – Dan Pichelman Mar 12 '13 at 14:10
  • 2
    Whether this is a solution or not depends on whether you actually care if someone works out the code. If it really doesn't matter that anyone can change anything, then this will be fine. But realise that it's just like leaving the bank vault key under the doormat, there is zero protection in this approach – Gareth Mar 12 '13 at 14:10
  • 2
    I see it as a $2 lock on an interior door of your house. It'll keep honest people out, but real crooks will bypass the door entirely and break through the wall. – Dan Pichelman Mar 12 '13 at 14:17
  • @DanPichelman I see the relevance of that analogy but all we're really talking about here is `base64_decode` and `base64_encode`. Hardly breaking the door. More like jiggling the lock because you looked at it and realized it wasn't closed all the way. – djechlin Mar 12 '13 at 14:48
  • @djechlin - I have to agree with you. One question - is `base64_decode` within the realm of "This system will be in a "trusted" environment and this users will have at best average IT skills."? – Dan Pichelman Mar 12 '13 at 14:52
  • @DanPichelman well, if you read my comments in the original question, you will see I feel the answer is "no," or at best "that is a business risk that needs to be evaluated seriously." Considering such questions as, might this system be later used for more secure/sensitive things, etc. I would generally not trust my corporate security on none of my "non-IT" employees enjoying hacking software by night. – djechlin Mar 12 '13 at 15:40
  • 1
    Honestly, this shouldn't be the only security. Security should be done at the server level, denying the user access if they don't have rights. Handling UI transitions can be done this way tho, since sensitive information is blocked at the server. – Fred Mar 13 '13 at 15:24
  • See this question for a really good explanation for why relying on obfuscation is not good security: https://stackoverflow.com/questions/4017757/encode-obfuscate-http-parameters – Dirbaio Mar 24 '15 at 05:11
  • 1
    I'm not saying that this is a good way to secure an application. He's looking for an easy way to obfuscate the parameters he's passing. The user has already logged in. He's seen all the comments about why doing something like this is a bad idea. My answer actually answers his question :) – Fred Mar 25 '15 at 15:36
  • base64 is **NOT** url safe – NFpeter Nov 02 '17 at 10:59
  • You can't BASE64 URL parameter generally speaking because the fact BASE64 encoding outputs both the characters '+' and '=', both of which are used in normal URL encoding. It's likely the receiving server will misinterpret the value. – johnsully83 Sep 04 '18 at 22:47
1

Params integrity can be ensured with HMAC. You generate hash using secret key and all the params, you include this hash inside of URL, then at server side you generate hash using same params and compare values.

function generateSignature(array $params, $hmacKey)
{
    // sort the array by key using SORT_STRING order
    ksort($params, SORT_STRING);

    $escapeFunc = function ($val) {
        return str_replace(':', '\\:', str_replace('\\', '\\\\', $val));
    };

    // generate the signing data string
    $signData = implode(':', array_map($escapeFunc, array_merge(array_keys($params), array_values($params))));

    // base64-encode the binary result of the HMAC computation
    $merchantSig = base64_encode(hash_hmac('sha256', $signData, pack("H*", $hmacKey), true));

    return $merchantSig;
}
sobstel
  • 1,432
  • 16
  • 11