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?


5 Answers 5


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.

  • 2
    @AlexPopov By getting a job at your company, for example.
    – Philipp
    Commented Mar 7, 2014 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
    Commented Mar 7, 2014 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
    Commented Mar 7, 2014 at 10:08
  • 2
    ...and it's sent in cleartext (which for me is the WTF here)
    – symcbean
    Commented Mar 7, 2014 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
    Commented Mar 8, 2014 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;

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.


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.

  • "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
    Commented Sep 8, 2015 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .