The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

114

Chapter 5 

■

Bypassing Client-Side Controls

70779c05.qxd:WileyRed  9/16/07  5:14 PM  Page 114

---

return hexEncode(checksum(input) + scramble(input));

}

private static String scramble(String input)

{

StringBuffer output = new StringBuffer();

for(int i = 0; i < input.length(); i++)

output.append((char)((input.charAt(i) - 3) + i * 4));

return output.toString();

}

private static String checksum(String input)

{

char checksum = ‘\0’;

for(int i = 0; i < input.length(); i++)

{

checksum ^= input.charAt(i);

checksum <<= ‘\002’;

}

return new String(new char[] {

(char)(checksum / 256), (char)(checksum % 256)

});

}

...

N OT E

For various reasons, Jad sometimes does not do a perfect job of

decompiling bytecode, and you may need to tidy up some of its output before it

can be recompiled.

With access to this source code, you can immediately see how your score is

converted into a long obfuscated string that has the characteristics observed.

The applet first appends some random data to your score (separated by the

pipe character). It takes a checksum of the resulting string, and also scrambles

it. It then prepends the checksum to the scrambled string and finally hex-

encodes the result for safe transmission within a URL parameter.

The addition of some random data accounts for the length and unpre-

dictability of the obfuscated string, and the addition of a checksum explains

why changing any part of the obfuscated string causes the server-side decoder

to reject it.

Having decompiled the applet back to its source code, there are various

ways in which you could leverage this to bypass the client-side controls and

submit an arbitrary high score to the server:

■■

You can modify the decompiled source to change the behavior of the

applet, recompile it to bytecode, and modify the source code of the