Posts Tagged ‘reporting’


Usually we know what bugs should be fixed. But that’s not always clear to other people at project. This problem appears usually with security issues. Project and product managers don’t usually see how some security issue or risk can be so destructive, that they should be high priority issues. Most proof of concepts from security issues are not real exploits, but rather “Hello world”-types because creating good proof of concept just costs too much to be justified.  Instead of writing POC, one should know how to write story about problem. And that’s what I’m now days usually doing when I submit security bug.

Every story has some common components. So must have every bug report which is telling the story. They should be:

  • Technical details at the beginning. The problem must be found easily by developer.
  • Actors. I’m always giving some kind of description who they are. Almost always there is one villain and victim, but villain can be also some innocent person, who just tries to get her work done more quickly.
  • Motivation. The villain has to have good motivation to exploit the bug.
  • Result. It should hurt someone, kill the business or reveal sensitive data.

For example:

Many PHP-applications has weak session handling. If the attacker can give own value for PHPSESSID, it is accepted and used by the application. Those can happen with cross site scripting bug or local access to the computer and tempering directly the cookie storage of Firefox. The tested application – women’s social site about home violence WSSAHV.COM – has weak session handling, but the tester didn’t find XSS. So report with story would be:

(Place technical details before the story. Also describing how the session should work.)

There is family and members are Hilma (wife) and Onni (husband). Onni is jealous. At some point he finds out that Hilma is using site WSSAHV.COM. Of course he suspects that she’s cheating or telling lies about him there. He directly doesn’t want to attack against her and force to give the password so he starts hacking and notices the weak session handling.

He has the administrator rights to their shared Windows desktop; he has also access to Hilma’s personal files. He goes to Firefox profile files, opens cookies.sqllite with sqllite. There he inserts new cookie for WSSAHV.COM. Domain is ‘WSSAHV.COM’, path ‘/’, name is ‘PHPSESSID ‘ and value is ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa‘, expiration is set to July 15th, 2020.

Next time when Hilma logs in to WSSAHV.COM, Onni has access to her profile from different computer. He just sets PHPSESSID at his machine to ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa‘. Onni can alter the profile, read the private message, and see the hidden areas where Hilma might have access and so on. This violates the privacy and meaning of the site. It also places the users to danger.

Advertisements