FLOSSHack for Participants

FLOSSHack workshops are a perfect event for those looking for an hands-on way to learn more about application security. Participants are encouraged to learn as much as they can about various common classes of vulnerabilities and then immediately apply that knowledge by auditing a real-world software system in a friendly hacking competition. A typical FLOSSHack event would work as follows:

1. An event organizer selects an appropriate open source software application for testing. Participants are notified at least one week in advance of the event date as to what the application is.
2. Eager participants get familiar with the target software and begin auditing the application on their own.
3. FLOSSHack workshop begins. Participants may join in person or remotely. Workshop sessions may last anywhere from 2 to 4 hours.
   1. At the beginning of the workshop, security experts may cover one or more common vulnerability classes or security topics that may be relevant to the application. This is designed to help participants learn how to find types of vulnerabilities they aren't as familiar.
   2. Participants share any vulnerabilities found prior to the work shop. Participants briefly describe their bugs and how they could be exploited. Open discussion is encouraged.
   3. Hacking begins. A pre-installed version of the application may be provided in some way, possibly on a VM or remotely. In this way vulnerabilities can be tested in addition to having code reviewed for flaws.
   4. Occasionally, when participants spot new vulnerabilities they should announce it and describe the bug to others. The resulting discussion may spark new ideas for finding additional flaws. (If things are "slow" in this area, the FLOSSHack organizer may stop everyone once in a while to cover some security topic that may help in further bug finding.)
   5. Conclude the workshop session with, hopefully, a pile of security bugs. Organizers may provide prizes for performances, such as most vulnerabilities found, or the "best" vulnerability found (as decided by participant vote).
4. Security flaws are compiled and sent off to application maintainers in a manner consistent with responsible disclosure. FLOSSHack organizers help facilitate this communication, but participants are given full credit for their finds (if they wish) once the issues are released publicly.

Remember, FLOSSHack is about helping secure target software, learning the art of hacking, and of course, having fun!

Submitting Quality Bug Reports

So you think you found a vuln? Fantastic! Here's what we need from you for your vulnerability to be counted in the competition:

• Specifics about what page and what input parameters were used to perform the attack. Provide full HTTP requests if possible.
• An proof of concept (PoC) exploit, or detailed description of the attack scenario. You ought to show that the flaw can truly be exploited in at least some configuration or deployment scenario of the target application.
• Recommendations for how to fix. If you can provide a code patch, great, but a detailed description of how the fix should look is fine too.
• Be reasonable in grouping your findings logically into bug reports. For instance, if you found an XSS in 10 pages all from the "...?FOO={evil}" URL parameter, then that would be considered a single vuln, not 10. Similarly, SQL injection through 5 form variables all fed into the same query would also be considered a single vuln.

Q & A

"I found a code quality problem, but it isn't an exploitable vuln... What should I do?"

Software maintainers almost always welcome suggestions on how to improve the way they do things. Feel free to send your FLOSSHack organizer the details on what you're seeing. It may not be counted as a vulnerability, but will still be shared with and benefit the project.