Cocktail String are a form of quick test that can be used in security testing. The idea is a general string with a mix of ending characters and other stuff that can be used for MySQL injections, XSS and similar. Here's the example I provided:
Where to use?
The string, or variations of it, can be used wherever users can send data to a server like in forms (especially look for hidden form named "id" and similar), cookies, file uploads, HTTP requests etc.
What are you looking for?
Exactly what to look for depends on context but here are a few suggestions:
- Any kind of errors like no database connection, faulty query errors, code errors etc.
- Garbage being printed on the page
- Any irregularities on the page (even subtle design changes like an extra line break)
- Check HTML code for occurrences of the string
- Check for errors in any logs
- If used in combination with databases, check the database content
- Check cookie content
I names my user this on a server application. Everything was fine until I started the administration interface, suddenly I couldn't see anything but a few garbage characters on a white background. The reason was the user's name wasn't sanitized on the admin pages but everywhere else.
Another similar example was when I used it as name for an item occurring in a log blanking out everything showing up after that log entry.
Finally I used it on a friend's project to highlight MySQL injection possibilities.
Ways to improve it
Many great suggestions to improve the string came up during the meetup. One was to add unicode versions of certain characters since this for instance fools some sanitation functions built into PHP as well as other sanitation plugins. Another was to add international characters including stuff like Arabic and Japanese. Finally Mattias suggested using an iframe instead of the comment tag at the end since loading a scary page is even more striking than blanking out half the page (as well as actually proving a really destructive bug exists). Cred to a lot of people for all the great suggestions (especially Simon for unicode, I'll add that for tomorrow's testing!).
Finally notice you'll have to change this string to fit your context, for instance a string used on an ASP.NET application or a Java desktop application looks different.
One interesting comment that came up was automating this (which is typically what security scanners do already, by the way). First off, it's suited really well for random automation that just sends various combinations of dangerous characters into every field it finds and compares for instance HTML output to a control. Might miss stuff / give a lot of false positives but still a great way to work with it. It also addresses one of the weaknesses with the string; since it uses so many different commonly filtered out characters the string might get filtered out due to one character while a couple of the other would have worked in isolation (this is typically what I mean when saying quick tests rarely provide evidence that a certain problem can't exist), with the speed of automation (assuming you achieve that) you could test them more one by one as well as in more combinations.
So a bit of a messy post but long story short:
Instead of Bob, name your next test user '"$%>*<!-- and let it live in the lovely city of '"<!-- with interests in '"$% and >*<.