I am reading OWASP Testing Guide v3:

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:


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

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?


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.

| improve this answer | |
  • 2
    @AlexPopov By getting a job at your company, for example. – Philipp Mar 7 '14 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 '14 at 8:53
  • 2
    Since the magic is in the query string, it will also be visible to other websites via the HTTP referrer. – Rob W Mar 7 '14 at 10:08
  • 2
    ...and it's sent in cleartext (which for me is the WTF here) – symcbean Mar 7 '14 at 15:59
  • 1
    Or if you didn't blocked search engines like Google, Bing, Yahoo from indexing that site, then probably the magic key may just appear at your Google search result :) Google Dork: site:www.host inurl:"/application?magic=" Or, if you're using other people's wifi connection and they're sniffing your http requests, they can get it easily as well. – wcypierre Mar 8 '14 at 2:12

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;
| 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.

| improve this answer | |

Wish I'd seen this sooner, but I'm just reading that OWASP Testing Guide myself. For me, the code snippet has the following obvious flaws:

  • Stored password is clear-text.
  • Stored password is compared against clear-text password provided by user
  • Password is stored in source code and could be committed to version control

That's like storing your user passwords in a database as clear text. If the database is hacked (or source code stolen), the password becomes immediately known. There's no excuse or reason to store clear text passwords. It's bad enough storing passwords that aren't salted or encrypted strongly.

To improve this code, and still leave the developer back door for testing...

  • Store a salted/hashed version of the string as an ENVIRONMENT variable (won't be be committed to a VCS)
  • compare stored encrypted string against salted/hashed version of clear-text password provided by user. (Similar to standard login)

In PHP, that might look like:

public function doPost(HttpRequest $request, HttpResponse $response){

    $admin = password_verify($request->get('magic'), $_ENV['ENCRYPTED_STRING']);

    if($admin) {
        $this->doAdmin($request, $response);
    } else {
        // do normal processing of request and response


This still leaves the problem of passing the clear-text password in a query string that could be logged or sniffed... but that's an issue outside the scope of the question.

| improve this answer | |
  • "Stored password is compared against clear-text password provided by user" I have never heard that this is a bad practice. Perhaps if the password propagates through a network or system to finally be checked, you might want to encrypt or hash it for transport, but other than that... if you didn't hash it client side (hello, mobile app developers!) there is usually little point in hashing it and then using it right after. Still, an upvote, you didn't say anything incorrect and there are some good points :) – Luc Sep 8 '15 at 18:04

In real attack scenario the finding magic parameter is almost bleak, as randomness in magic parameter is enough high to protect it from probable brute force attack. However when it comes to source code review it is clearly mention that if magic parameter matches the random hash, the user will land in admin dashboard.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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