Hans used less XML, and now he had two problems.

He was used to the reporting webservices not working. The application had its own special ways of doing security. Often it could be traced back to forgetting the Important Special Code: a http header needed in every request.

     myauth: productname: WweoEdL92873

Productname was never actually a product name. After all, it couldn't be any specific product name. That little snippet was copy and pasted character-for-character into every piece of code. Yes, that includes the none-too-helpful "productname". And yes, that includes the hardcoded "Important Special Passphrase".

Of course, that didn't stop developers from screwing up that one line. Sometimes it was whitespace or a BOM introduced by their IDE of choice/Notepad. Other times it was a bit-flip error introduced by their meat-based clipboard (who can trust ctrl-c / ctrl-v in these hectic, Enterprise Cloud-based times?).

But today was different. Rather than Hans' report not working at all, it was working far, far too well. The report was a Single User Report that reported on several sensitive and private statistics. The logged in and authenticated user should see data about themselves, while non-logged in user should see nothing.

Instead, the unauthenticated user was seeing everything about everyone. The webservice he called was returning private and sensitive data about every single user in the entire system. Hans was used to his reports crashing, falling down, failing spectacularly, corrupting data, reporting incorrect sums and having the wrong dates-- but this was one step beyond. <!-- Madness!!! -->

The only difference in his code was that an authenticated user sent their username in the request XML.

     <request type="GetSensitveUserData">
           <username>Hans</username>
      </request>

Unauthenticated users omitting the username element.

With the uneasy feeling one often gets moments before coming across code to submit to The Daily WTF, Hans pulled up the code for the GetSensitiveUserData webservice.

     // automatically filter results according to loggedInUser
     User requestUser = request.getUser();
     
     // filtering. Becomes WHERE clause
     Criteria criteria = new Critera();
     if (requestUser != null)
     {
            if (requestUser instanceof Employee)
            {
                 Employee employee = (Employee) requestUser;
                 criteria.add(Restrictions.eq("partner", employee.getPartner()));
            }
     }
     return GetSensitiveUserDataQuery(criteria);

And thus, by omitting the Username (as any unauthenticated user would do), the Webservice allowed access to the data without any restrictions