Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am reading OWASP Testing Guide v3. The following passage:

Example 1: Magic Parameters Imagine a simple web application that accepts a name-value pair of “magic” and then the value. For simplicity, the GET request may be: http://www.host/application?magic=value To further simplify the example, the values in this case can only be ASCII characters a – z (upper or lowercase) and integers 0 – 9. The designers of this application created an administrative backdoor during testing, but obfuscated it to prevent the casual observer from discovering it. By submitting the value sf8g7sfjdsurtsdieerwqredsgnfg8d (30 characters), the user will then be logged in and presented with an administrative screen with total control of the application. The HTTP request is now: http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d Given that all of the other parameters were simple two- and three-characters fields, it is not possible to start guessing combinations at approximately 28 characters. A web application scanner will need to brute force (or guess) the entire key space of 30 characters. That is up to 30^28 permutations, or trillions of HTTP requests! That is an electron in a digital haystack! The code for this exemplar Magic Parameter check may look like the following: public void doPost( HttpServletRequest request, HttpServletResponse response) { String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”; boolean admin = magic.equals( request.getParameter(“magic”)); if (admin) doAdmin( request, response); else .... // normal processing }

ends with:

By looking in the code, the vulnerability practically leaps off the page as a potential problem.

As I am a beginner, I don't see the vulnerability in the code right away. Could someone explain what exactly is wrong with the code?

share|improve this question

3 Answers 3

up vote 3 down vote accepted

Here, if a user knows the magic string he gains admin privileges if he sends a request which contains the string "sf8g7sfjdsurtsdieerwqredsgnfg8d" as value for the parameter "magic".

Magic credentials / strings are often used by developers for testing. Often they forget to remove them when deploying the application to production stages which results in a vulnerability.

share|improve this answer
    
To know the magic string, one needs access to the source code. How would they gain access to the source code easily? –  Alex Popov Mar 7 at 8:43
2  
@AlexPopov By getting a job at your company, for example. –  Philipp Mar 7 at 8:46
3  
For example through social engineering. The attacker could send a phishing email to someone who has access to the source code repository. The email could contain a malicious pdf or a link to a malicious website containing a drive-by-download. When the developer opens the pdf or visits the website malware is installed on the developer's computer which gives the attacker access to it. –  DanielE Mar 7 at 8:53
1  
Since the magic is in the query string, it will also be visible to other websites via the HTTP referrer. –  Rob W Mar 7 at 10:08
    
...and it's sent in cleartext (which for me is the WTF here) –  symcbean Mar 7 at 15:59

Actually there is another more important one, due to the lack of a time constant implementation of equals, a timing attack can be used to work out magic.

See http://codahale.com/a-lesson-in-timing-attacks/

public static boolean isEqual(byte[] a, byte[] b) {
    if (a.length != b.length) {
        return false;
    }

    int result = 0;
    for (int i = 0; i < a.length; i++) {
      result |= a[i] ^ b[i]
    }
    return result == 0;
}
share|improve this answer

There is no inherent vulnerability in the code snippet itself as it doesn't appear prone to injection - assuming of course that the local magic variable doesn't get exposed somewhere in the 'normal processing' code down the line. One could discuss about the code quality, but I can't see what would make it vulnerable in this instance.

The vulnerability of the whole thing comes from the design.

Of course nobody will attempt to find the magic string by shear brute force - it would take time, it would end up in the server logs and it would be easily discovered much before any statistical chance of guessing the magic string. Instead the easiest attack on the whole system is to place yourself in front of the server (or at any point between legit admin users and the server, public WiFi being the best bet if the admins are dumb enough) and cache request packages sent to the server - sooner or later an admin would log in and practically give you the magic string on a silver platter.

And that is all assuming that the server itself is properly secured - if it leaks access logs, or backs access logs to an unsecured location, you don't even need to perform network foo in order to obtain the magic string.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.