Encrypted query string variable xml



  • I'm assigned a task which involves me needing to programmatically write requests to our application. The requests are pretty straightforward, something like http://example.com/getitem.aspx?itemid=XXX.

    However as I'm doing this I notice the item id value is hex encoded. There's really no need for this but based on the number of WTFs I encounter with this thing on a daily basis, I just accept it for what it is and change my code to encode the item id in hex first.

    Except, the values still don't match. To try to figure out what's going on I decode one of the item ids from a working url, and it has the telltale signs of being an encrypted string. I ask around, and sure enough, we're encrypting the item ids in the URL. Someone tells me where the encryption method is (of course it's buried in some massive static "class" named "Utilities" with a super descriptive name "ESTR") so I dig through the code and find it. Hardcoded encryption key, pretty solid evidence the original developer had no idea what the IV is meant for, and using the 3DES algorithm with a single key (which makes it as secure as DES, a broken algorithm , except it just takes 3 times longer to encrypt strings). Still a mild WTF compared to what I see, so I just sigh and include a call to the encryption method in my program to make the query string.

    And of course it still doesn't work. Do some more digging through the spaghetti only to find the following is done to create the itemid value in the urls:

    1. Create a new XML document
    2. Add a node "item".
    3. Add another node to the "item" node ItemId with inner value = the item's id.
    4. Encrypt innerxml of item node and return as querystring value.


  • If you want to improve this, you could serialize the value then return a BSON document. Horrible to maintain but looks good on the resume.



  • @bullrider718 said:

    3DES

    I think you're thinking of 3rot13.



  • I wouldn't say DES is a "broken algorithm". It can be brute-forced because the key is so short, but that's not the same thing as having a cryptoanalytic flaw.



  • @Ben L. said:

    @bullrider718 said:
    3DES

    I think you're thinking of 3rot13.

    3DES (with three keys, not the one in the OP) is still pretty secure. I wouldn't use it for anything new, but it's still serviceable.



  • @bullrider718 said:

    getitem.aspx

    I'm not surprised.



  • @ubersoldat said:

    @bullrider718 said:

    getitem.aspx

    I'm not surprised.

    I'm more of a gelegem, myself.



  •  geteisem.







  • @bullrider718 said:

    I ask around, and sure enough, we're encrypting the item ids in the URL. Someone tells me where the encryption method is (of course it's buried in some massive static "class" named "Utilities" with a super descriptive name "ESTR") so I dig through the code and find it.

    Because it would be too useful to have a single method which takes the parameter and returns the querystring.



  • @pjt33 said:

    @bullrider718 said:
    I ask around, and sure enough, we're encrypting the item ids in the URL. Someone tells me where the encryption method is (of course it's buried in some massive static "class" named "Utilities" with a super descriptive name "ESTR") so I dig through the code and find it.

    Because it would be too useful to have a single method which takes the parameter and returns the querystring.

    I like that it's XML-wrapped, encrypted and hex encoded. That "item ID" must be 40 digits long!



  • @morbiuswilters said:

    @pjt33 said:
    @bullrider718 said:
    I ask around, and sure enough, we're encrypting the item ids in the URL. Someone tells me where the encryption method is (of course it's buried in some massive static "class" named "Utilities" with a super descriptive name "ESTR") so I dig through the code and find it.
    Because it would be too useful to have a single method which takes the parameter and returns the querystring.
    I like that it's XML-wrapped, encrypted and hex encoded. That "item ID" must be 40 digits long!
    If someone brute forces the encryption, you need another layer to keep them busy for at least another six seconds.  Defense in depth.



  • @dhromed said:

     geteisem.

    Gesundheit

     



  • @bullrider718 said:

    Hardcoded encryption key, pretty solid evidence the original developer had no idea what the IV is meant for, and using the 3DES algorithm with a single key (which makes it as secure as DES, a broken algorithm , except it just takes 3 times longer to encrypt strings).

     

    This is how I know this story is pure hogwash.

    Everyone knows real Enterprise developers encrypt sensitive, highly-visible, client-accessible strings with Base64.

     



  • @Jaime said:

    If someone brute forces the encryption, you need another layer to keep them busy for at least another six seconds.  Defense in depth.

    This is why I always use MorbsCrypt™ for my sensitive data! Of course it uses AES-128, but it also hides your data in about 17gb of porn. We've got everything in there--straight, gay, furry, even those sickos who are into Asian chicks! By the time they find your data, they're too exhausted to do anything with it. And that's assuming they don't just keel over from dehydration first.



  • @dhromed said:

    @morbiuswilters said:

    @dhromed said:

     geteisem.

    Tennessee's Early Intervention System?

     

    no no,

     


    derchroomd vraak


Log in to reply