QueryCrypt 1.0 Released - Encryption for URL Parameters

Discussions

News: QueryCrypt 1.0 Released - Encryption for URL Parameters

  1. Aveda Technology has released QueryCrypt 1.0 which enables the encryption of URL parameters at the presentation layer of the web application. This secures your web application from a potential hacker manupulating the query request to gain access to sensitive data by altering parameters.

    For example, if click-throughs expose any ids on an anchor tag (i.e., <a href="Eigenvaluehttp://foo.bar.com/stuff.do?id=1234">Eigenvalue>), it's conceivable that a malicious user might replace that id with another value to attempt to gain access to data without authorization. While applications are responsible for protecting their own data, QueryCrypt provides the ability to translate that into something more secure: for example, it might look like <a href="Spacklehttp://foo.bar.com/stuff.do?_tq=16agdt15272563123">Spackle> instead, and as this is an encrypted value based on the session id and a DESede, it's very difficult for the data to be exposed or exploited.

    It works via a session listener, and simple API calls are provided to construct or deconstruct query parameters.

    QueryCrypt sells for $300 USD, and can be bought online.

    Tell us what you think of this new product. Are there way in which it can be improved?

    Threaded Messages (37)

  2. $300 for simple function call ???[ Go to top ]

    I do not understand how people can charge $300 for something that is so easily and quickly implemented using open-source and freely available libraries. :))
    I've been encrypting my webapp urls for a long time already.
  3. $300 for simple function call ???[ Go to top ]

    Comrade, what is wrong with charging money for one's efforts?
  4. $300 for simple function call ???[ Go to top ]

    Comrade, what is wrong with charging money for one's efforts?

    I'm not questioning fact of charging money.
    I'm questioning amount :))
  5. $300 for simple function call ???[ Go to top ]

    Hi Vagif

    I've been looking for some time an api that would allow me to accomplish this. could you tell me which libraries you use?
    thanks in advance
    Patria
  6. Free java crypto library[ Go to top ]

    I'm using this:
    http://www.cryptix.org/
  7. What libraries does QueryCrypt use?[ Go to top ]

    At present we use Sun's implementation of the JCE specification. And together with their Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 you can increase the key strength. At present we are working on migrating to the JCE implimentation by bouncycastle.org.

    Some of the new features that should be available soon are:
  8. Ability to specify key size/strength
  9. Ability to choose between DESede or AES encryption

  10. And on a side-note from all the other comments we read... QueryCrypt is not here to replace your application's security. We do not in any way suggest that you remove/replace your login code or your security checks that should be in place to make sure that the right user is seeing the right data. While applications are responsible for protecting their own data, what we offer is a way to hide the query parameters that might expose some of the variables and values that may be used within your application. Information such as this can potentially give a hacker some level of advantage and may expose a flaw that the developer might have overlooked during their development phase.
  • Session timeout?[ Go to top ]

    Err... what will you do if the session times out or if someone bookmarks the page?? $300.00 for nothing if you cannot automatically handle this case!
  • While applications are responsible for protecting their own data...
    Exactly.
  • While applications are responsible for protecting their own data...
    Exactly.
    Agreed.

    But sometimes tools like this and debuggers are needed for people that do not want to spend as much time understanding and making their code correct.

    Although I sometimes use a debugger if I have to figure out why someone else's code does not work.
  • What are the use cases?[ Go to top ]

    For example, if click-throughs expose any ids on an anchor
    > tag (i.e., Eigenvalue ), it's conceivable that a malicious user
    > might replace that id with another value to attempt to gain
    > access to data without authorization.

    Most of the time you protect sensitive data using credentials and you NEVER assume that the user trying to retrieve the data is the one with the right credentials. Encrypting the URL if you don't do these checks first is a half baked security policy.

    If you are returning important information in the URL itself (e.g. ?password=...), then I would question the design of the web application.

    I believe there are few cases where sensitive data is returned without auth² being done. Comes to my mind online parcel tracking applications.

    But in that case, the transport company was not necessarily in direct relation with the customer in the first place, making it harder to attribute credentials. In those rare cases, it's a tradeoff between apparent security and ease of use. You can change the system to not display the parcel id in the url (e.g. using POST instead of get), but that doesn't prevent someone with knowledge of the ID to retrieve the same information.

    So what are those use cases that are not solved by using proper authorization/authentication?
  • What are the use cases?[ Go to top ]

    If you are returning important information in the URL itself (e.g. ?password=...), then I would question the design of the web application.

    Who cares if it's a GET or a POST? You use TLS if you want security. Anything with a password in it should be submitted via https or it isn't secure, period.
  • on target[ Go to top ]

    If you are returning important information in the URL itself (e.g. ?password=...), then I would question the design of the web application.

    Who cares if it's a GET or a POST? You use TLS if you want security. Anything with a password in it should be submitted via https or it isn't secure, period.

    glad someone had the courage to say it. encrypting the URL gives a false sense of security and is rather easy to beat for someone that actually wants the data. Given the variety of options today for SSL/TLS acceleration, there's no "good reason" for a company to take the cheesy way out and make customer data vulnerable.

    peter
  • on target[ Go to top ]

    If you are returning important information in the URL itself (e.g. ?password=...), then I would question the design of the web application.
    Who cares if it's a GET or a POST? You use TLS if you want security. Anything with a password in it should be submitted via https or it isn't secure, period.
    glad someone had the courage to say it. encrypting the URL gives a false sense of security and is rather easy to beat for someone that actually wants the data.

    Given the variety of options today for SSL/TLS acceleration, there's no "good reason" for a company to take the cheesy way out and make customer data vulnerable.

    peter

    What do you think of yahoo mail then? By default, they do not use https to send username and password. Instead, they send password's digest: http://pajhome.org.uk/crypt/md5 If you care more about traffic sniffing than of trojans in your own browser, then this is not the worst thing. Of course, not for *sensitive* information, but anyone can read my email anyway.
  • on target[ Go to top ]

    If you are returning important information in the URL itself (e.g. ?password=...), then I would question the design of the web application.
    Who cares if it's a GET or a POST? You use TLS if you want security. Anything with a password in it should be submitted via https or it isn't secure, period.

    glad someone had the courage to say it. encrypting the URL gives a false sense of security and is rather easy to beat for someone that actually wants the data. Given the variety of options today for SSL/TLS acceleration, there's no "good reason" for a company to take the cheesy way out and make customer data vulnerable. peter


    What do you think of yahoo mail then? By default, they do not use https to send username and password. Instead, they send password's digest: http://pajhome.org.uk/crypt/md5 If you care more about traffic sniffing than of trojans in your own browser, then this is not the worst thing. Of course, not for *sensitive* information, but anyone can read my email anyway.

    Right, Yahoo does exactly that for yahoo email, since they tell users it's not secure. On the otherhand, if you use Yahoo Wallet, it requires secure login. Yahoo isn't stupidly using URL encryption for things that matter, like sensitive user data. The information stored with email accounts isn't sensitive. The emails you store on Yahoo may be sensitive, but that is up to each user's descretion. If someone gets hacked because they're storing sensitive data in their yahoo inbox, I consider it "user error."

    Yahoo also has a wide variety of systems and databases, so sensitive data isn't stored on the same system as the email application. I could be wrong, since I don't work for yahoo. I have had to integrate with yahoo in the past and their setup is rather complex.

    peter
  • If you are returning important information in the URL itself (e.g. ?password=...), then I would question the design of the web application.
    Who cares if it's a GET or a POST? You use TLS if you want security. Anything with a password in it should be submitted via https or it isn't secure, period.
    glad someone had the courage to say it. Encrypting the URL gives a false sense of security and is rather easy to beat for someone that actually wants the data. Given the variety of options today for SSL/TLS acceleration, there's no "good reason" for a company to take the cheesy way out and make customer data vulnerable.peter

    QueryCrypt is not here to replace your application's security. Here is a scenario where this might apply. Say you have an account with Bank ABC and so does a hacker. You both log into your account for "Online Banking". Both of you are using HTTPS/128-bit or more SSL, while you might be legitimately using the online banking application, the hacker might be using the bank account to find vulnerabilities in the application that might allow them more access. Both of you are account holders but each with a different intention. By exposing your query parameters, you are giving the hacker an edge into your application. So why not secure it?

    Furthermore, we are not suggesting that you replace HTTPS/SSL or your application's security. We are presenting you with an option to further enhance your application's security, so that it makes it that much more difficult for a hacker to understand your back-end.

    And once again, we welcome your comments and suggestions on making this a better product.

    Venkatt Guhesan
    Aveda Technologies, Inc.
  • Who cares if it's a GET or a POST? You use TLS if you want security. Anything with a password in it should be submitted via https or it isn't secure, period.

    glad someone had the courage to say it. Encrypting the URL gives a false sense of security and is rather easy to beat for someone that actually wants the data. Given the variety of options today for SSL/TLS acceleration, there's no "good reason" for a company to take the cheesy way out and make customer data vulnerable.peter

    QueryCrypt is not here to replace your application's security. Here is a scenario where this might apply. Say you have an account with Bank ABC and so does a hacker. You both log into your account for "Online Banking". Both of you are using HTTPS/128-bit or more SSL, while you might be legitimately using the online banking application, the hacker might be using the bank account to find vulnerabilities in the application that might allow them more access. Both of you are account holders but each with a different intention.

    By exposing your query parameters, you are giving the hacker an edge into your application. So why not secure it? Furthermore, we are not suggesting that you replace HTTPS/SSL or your application's security. We are presenting you with an option to further enhance your application's security, so that it makes it that much more difficult for a hacker to understand your back-end.And once again, we welcome your comments and suggestions on making this a better product.Venkatt GuhesanAveda Technologies, Inc.

    I can see the value of using URL encryption, but not as a security feature. It's an obfuscation feature in my mind to keep competitors from figuring out how the website works. In terms of using URL in a bank situation, I find that rather unlikely. Banks have some rather strict laws to adhere to and generally do not stick a bunch of request parameters in the URL. Depending on how "careful" a bank is, they might use POST + SSL + encrypt request parameters and pragma no-cache. The least of their worries is URL encryption, so I 'm totally bias and don't buy that (bank scenario) as a valid use case.

    I'm sure there are plenty of valid use cases for URL encryption like Yahoo or other public sites that want to hide how their application works.

    peter
  • This demonstrates a basic misunderstanding of cryptography and its uses. Here's why:

    The problem is to prevent unauthorized access to URLs by "URL-sniffing": changing the values of parameters on a POST/GET to try to access data that should be inaccessible. This is a valid problem, as there ARE occasional situations where SSL is not reasonable, in particular where any single session is unimportant, but each needs to be kept distinct and reasonably secure.

    The flaw is in the solution: Why in the world would you need any advanced cryptographic protocols to acheive security from URL-sniffing? It would be far more easy to do a simple "one-time pad" approach: Store a sufficiently long string of random characters in a database with each response, or each valid action a user can take. On the corresponding request, verify against the previously created random String. This is also more secure, as each request would have to be attacked individually. It's also far less intensive computationally. Using these advanced encryption routines actually serves to make things LESS secure as any successful attack could break every URL string, not just the one being attacked.

    Rather frightening that this worthless product came so far along.

    --bpo
  • What are the use cases?[ Go to top ]

    Anything with a password in it should be submitted via https or it isn't secure, period.

    https will not save you from malicious user, who can easily register on your web site (even paid subscription), and this way bypass https and start playing with URL parameters to get access to other users data.

    So you have really have only 2 options check full access rights on each url (which is cumbersome, time consuming, and adds too much pain into programming) or encrypt url parameters making impossible to end users fooling around with url parameters.
  • What are the use cases?[ Go to top ]

    I can see the only use case for such feature:

    Imagine that you want to enable authenticated user to download certain file or display some page. But he must always confirm that he agrees your terms. So you pass file location as parameter to another servlet, that does the logic. If the parameter is confuscated, you can minimize the chance, that he can pass another value and bypass your routine.

    Hmm, such use case seems artificial and it could be solved with sessions in much more secure way.
  • What are the use cases?[ Go to top ]

    As I understand it can be used to replace authorization only. If you trust this library then it doe's not make sence to write authorization code, if you do not trust it then it doe's not make sence to use it.
  • In one of our projects, we spent few days developing a small utility that does exactly the same thing.

    Basically, the ideas is to generate a symmetric key (for performance) by using SUN JCE (IBM JCE is also easy to use) when starting your web server. Moreover, an idea you may be interested in is to convert each character of the encrypted text to hexi code for the purpose of avoiding the characters like "+", "=" or ";" in the encyrpted text, which may cause the decripting trouble.

    Anyway, if anybody is interested, a free copy can be sent to you,
  • haha what a joke[ Go to top ]

    wouaou.. some people don't have any problems releaseing "products" which can be built better in 3 standard function calls.
  • It is half-baked[ Go to top ]

    The release states:

    "...enables the encryption of URL parameters at the presentation layer of the web application. This secures your web application from a potential hacker manupulating the query request to gain access to sensitive data by altering parameters."

    I don't think Aveda suggests using their product instead of SSL. This is definitley a half-baked security scheme. Consider this:

    A user logs into a secure website and examines his credit card info via a URL like: .../viewPaymentInfo.do?userId=123. Should he be able to change "123" to "456" and see another users CC info? Certainly not. Simply encrypting the value is not the best answer. A check on the server side should ensure that logged-in-user "123" can only see the info for user "123"! And that's the bottom line here.

    And in reply to the user who commented that role-checking for each URL is "too hard", I say look at Struts. It integrates seamlessly with servlet container authorization. Simply add "roles=SomeRole, SomeOtherRole" to the action mapping. Heck, even rolling your own authorization is simple!
  • It is half-baked[ Go to top ]

    This is definitley a half-baked security scheme. Consider this:A user logs into a secure website and examines his credit card info via a URL like: .../viewPaymentInfo.do?userId=123. Should he be able to change "123" to "456" and see another users CC info? Certainly not. Simply encrypting the value is not the best answer. A check on the server side should ensure that logged-in-user "123" can only see the info for user "123"!
    URL encryption and HTML level security is useless for secure application.
  • While I tend to agree that the library seems overpriced, URL signing and encryption is not useless. It is especially useful when transferring between systems on different servers, where one system makes the access decisions based on information the other one doesn't have.

    A simplified example from a system I have designed: Assume the user accesses a menu system with links to the content he is allowed to see (based on business rules). Another system handles the actual content.

    Now, the menu system will generate URL's like

    /content/showContent?id=123&sign=AB234fGe where the
    sign is a base64 encoding of MD5('/content/showContent?id=123'+shared_secret)

    Now, the content system has a simple filter to verify sign parameters, and the two systems have a shared secret that's inaccessible to the user.

    In our example, one system was ASP based, while the other was java. And the MD5 checksum was also computed based on the username provided by a reverse proxy and a timestamp.
  • Secure applications are integrated on server side using stuff like this http://xml.apache.org/security/
  • Re: It is half-baked[ Go to top ]

    In the case of taking care about IDs, I believe the best option is using UUIDs, not incremental IDs.

    this gives a URL like this:

    /open.x?uuid=AOdjaoiJQ2398dsa9ASdhsadh1239ehsaDSAH2

    for sure, this kind of ID will NOT give the user a chance to guess the next record... :)
  • Good Idea[ Go to top ]

    Sounds like a good idea and as evidenced by the responses, not a scenario that most non-hackers think about. The only problem, is that it seems pretty easy to build yourself in a few hours. I think it would be nicer if you could just use the HttpServletRequest interface and a filter, overriding the getParameter type methods. That way you don't have to worry about when to use the encrypted instance or even if a parameter has been encrypted. I think you can do this by storing all the parameters in a Map and then adding the encrypted parameters if the proper queryName is found.
  • Good Idea[ Go to top ]

    I don't propose that it is a bad idea in any way other than to completely replace a true authentication and authorization mechanism.

    Easy to build? Sure is. You need:

    1. Custom tag to generate encrypted URL's (you can extend Struts link tag easily)
    2. Custom tag to generate encrypted hidden tags (again, simple Struts extension)
    3. A servlet filter to check for submitted encrypted parameters, which when found creates and passes down the line:
    4. A "DecryptedHttpServletRequest" which is a simple HttpServletRequestWrapper
    5. An encryption utility class

    As you encrypt stuff in the tags place the param names in a Collection so that you know what will be coming back encrypted. You can do this at the session or servlet context level depending on your requirements.
  • How about post data?[ Go to top ]

    Since most data is submitted by a form, how would this work with post data? Do you simply encrypt the value?
  • Here's an idea[ Go to top ]

    Here's an idea for handling form data:
    You can re-interpret both the name and value of an input field from:

    name="id" value="10"
    name="size" value="medium"

    to this:

    name="encrypt_form_key" value="id:10"
    name="encrypt_form_key" value="size:medium"

    which can then be hidden via encryption and I guess you can use a hash for the name to keep it unique.

    name="18310289" value="21982130129"
    name="183ssdfd" value="31231231233"

    then get all the parameter names and see if the hash matches, and decrypt and translate the values into the original name/value pair.

    I guess.
  • Ignore top message[ Go to top ]

    I see this idea doesn't work. Hey, isn't there a way to erase your own messages?
  • nope[ Go to top ]

    I see this idea doesn't work. Hey, isn't there a way to erase your own messages?

    it's one of the features of TSS.com. It's all good though. I've wanted to remove my own post in the past, but it's kinda funny. there's nothing quite like reading one's own posts to get a reminder that we all make mistakes :)

    peter
  • shame, shame...[ Go to top ]

    1. I doubt that anyone who is seriously concerned about the security of their web application would benefit from this software - due to the things that many posters have already pointed out.

    2. It bothers me that products like this may actually confuse those who lack knowledge and understanding of the issue, and, trick suck follks into a false sense of security.

    3. It would indeed take most of us here a few hours to implement a similar solution.

    4. Regarding the price tag... A fully-functional personal licence for IntelliJ IDEA is only $249... Hello-ooo! Well, I guess, it never hurts to ask, Mr. Guhesan...

    5. And finally, is it appropriate to use this forum to shamelessly promote your personal products? That's just a question... perhaps there;s nothing wrong with it... ;)


    Oh, and by the way... I went to the Aveda web site... It looks like Mr. Guhesan (a.k.a. Aveda Technology) is simply an incorporated individual, like many of us, and I applaud his effort in creating a professionally-looking site. (I entered the address for the "J2EE and Java Services Division" of the "company" into GoogleEarth and it pointed me to a cute little house in a _very_ residential area in Maryland. :) Nice try! I am not sure whether I approve of this bold self-promotion, but I wish the guy had a more useful, less confusing product to offer - for a reasonable price.

    Cheers.
    C
  • typo[ Go to top ]

    oops... typo: "suck follks" = "such folks". thought i'd clarify that... :)
  • 1. I doubt that anyone who is seriously concerned about the security of their web application would benefit from this software - due to the things that many posters have already pointed out.

    QueryCrypt is not here to replace your security of the application. While applications are responsible for protecting their own data, what we offer is a way to hide the query parameters that might expose some of the variables and values used within your application. That's It! Nothing more, nothing less!
    2. It bothers me that products like this may actually confuse those who lack knowledge and understanding of the issue, and, trick suck folks into a false sense of security.

    What aspect of the product do you find confusing? Is the name "QueryCrypt" confusing or is what we say it does - which is - "it hides your query parameters" - confusing? I would like to know so that I can develop a better product or write a better product description that meets your expectations.
    3. It would indeed take most of us here a few hours to implement a similar solution.

    Well, it took me three hours of development time to develop this product and about two hours of web design and website documentation for this particular product. And if you are say - a middle of the road Java developer charging about $80 per hour for your time. That adds to about $400 for the work I have done. When someone buys your product you obviously provide support because you believe in your product and you spend about say an average of about one hour of your time helping the individual effectively use your product and now I have roughly spent about $480 of my time. And to keep this discussion more at a developer level, let's not discuss the income tax I'll have to pay on this income as well as my headaches that come with taxes :-) and the credit-card transaction fees I would have to pay for the online transaction. So the question I ask you is - what is the value of five to six hours of my time and more importantly what is the value of the two to three hours saved by the developer who uses this API instead of developing their own. I'm sure you (and a lot of others who have commented above) can spend the two or three hours of your time developing this product and I'm sure given sufficient time you will come up with a Mona Lisa of QueryCrypt but what I'm saving you is the opportunity cost of that two to three hours.
    4. Regarding the price tag... A fully-functional personal license for IntelliJ IDEA is only $249... Hello-ooo! Well, I guess, it never hurts to ask, Mr. Guhesan...

    So what is the appropriate price tag for a product like this? Once you download the API, you are free to use it in as many servers as you wish. No restriction on distribution. As a developer, you can encrypt URLs on as many servers as you wish and you are entitled to updates for rest of your lifetime. So is $30 instead of $300 an appropriate fair price? You tell me Constantine! And just because you and others commented on the high price, I've brought it down to $30, so let’s see how many I sell? And maybe you can provide me with better advice on what is the fair price for a product such as this. I'm always open for ideas.
    5. And finally, is it appropriate to use this forum to shamelessly promote your personal products? That's just a question... perhaps there’s nothing wrong with it... ;)

    Is it wrong for me to let the world know of something I believe might be useful to someone out there? During my development of a different application, I had it fully secure. It used JAAS with form authentication on top of SSL (HTTPS) with method and class level security. But I still felt that it was not 100% secure. I'm sure you and other developers who strive for 110% know this feeling. And for my own sake, I needed to encrypt the query parameters. So I sat down and developed QueryCrypt. And once it was developed, I needed to share it with the world in hopes that someone out there might have a similar need for QueryCrypt. I didn't hide what it did. I didn't offer to solve all of the Java and web developments’ security needs of an application. The tool just hides the query parameters and nothing more and nothing less. And everyone is entitled to question it and to choose to buy or not buy the product. So what is the shame in it? I'm not any different from the starving artists or the fruit vendor down the street.
    Oh, and by the way... I went to the Aveda Technology web site... It looks like Mr. Guhesan (a.k.a. Aveda Technology) is simply an incorporated individual, like many of us, and I applaud his effort in creating a professionally-looking site. (I entered the address for the "J2EE and Java Services Division" of the "company" into GoogleEarth and it pointed me to a cute little house in a _very_ residential area in Maryland. :) Nice try! I am not sure whether I approve of this bold self-promotion, but I wish the guy had a more useful, less confusing product to offer - for a reasonable price. Cheers.C

    And thank you for the comment about the 'cute little house' and 'a professionally-looking site'. I appreciate the comment and yes, I - like most developers who dream of having the piece of the pie, do most of my development from my house. And when I can afford something more, you will definitely see me in a more professional office building. But this is where I am for now.

    So I leave you with the question - what is the fair price? $300 or $30. And just because you (and others) took your time in commenting about QueryCrypt, I have listed the price as $30 and I'm going to call it the "Constantine Discount"... :-)

    I look forward to your comments as well as others. And for all the folks who took the time to patiently read through my comments – I thank you and you too are entitled to the “Constantine Discount” should you choose to try it. ;-)

    Venkatt Guhesan
    Aveda Technology
  • QueryCrypt is now free for download...[ Go to top ]

    QueryCrypt is now free for download... QueryCrypt from Aveda Technology