次の方法で共有

Catch the Security Flaw #3

  • [アーティクル]

Quite a few web applications encrypt query string values. This is generally done as an added measure to prevent unauthorized access. Since the end user cannot chose a value and then encrypt it, changing parameters becomes difficult. But encryption is not a panacea. See if you can spot this bug.

encrypt1

The code behind file looks like this:-

encrypt2

Implementation for the Encrypt and Decrypt methods is not shown. They are using the DES algorithm. There is no flaw in the usage or key management.

The end user can upload files and the screen look like this:-

encrypt3

On clicking Upload, the file gets uploaded and a message is shown. Note the query string values. The HTML source is also shown.

encrypt4

Do you think the code or design is flawed in any way? Can this be exploited?

Comments

  • Anonymous
    July 14, 2008
    At first glance, it looks like the encryption is being done server-side, which would result in the file being transmitted to the server in the clear.

  • Anonymous
    July 14, 2008
    You also have the 2 values unencrypted.  It would be fairly easy to reverse engineer the encryption method.  You could then inject some javascript into the DoSomething method.

  • Anonymous
    July 14, 2008
    "'" and ";" are valid characters in file names and could be used to inject Javascript into the page without the need for script tags, thereby bypassing the built-in validation. The file name would be the injected javascript, eg. ';eval(window.name);'. The initial upload by the user would prepare the URL that could be sent to another person as a session hijacker. The Javscript could potentially steal the session cookies (unless httpOnly cookies was implemented in web.config and supported by the web browser of the victim) or could be used to capture keypresses and/or iframe a spoof page requesting a login for example. If anything, the encryption makes it more dangerous because the recipient of the prepared URL can't determine the risk of clicking simply by seeing some Javascript in the URL. If length or variety of available characters is an issue, remember the injection could always make use of window.name to store additional Javascript from the attacker's web site. Do I win a cookie? :)

  • Anonymous
    July 14, 2008
    The comment has been removed

  • Anonymous
    July 14, 2008
    Varun, the Server.UrlEncode is wrapped around the encrypted result, not the file name, so I don't think that will be a problem.

  • Anonymous
    July 14, 2008
    Ah, I see now, sorry. Default.aspx not Default.aspx.cs.

  • Anonymous
    July 14, 2008
    The final step might be to take the encrypted result for the file name in my method and insert it as the value for status.

  • Anonymous
    July 14, 2008
    Bingo! You are absolutely correct!