FLOSSHack for Participants - Revision history

TimMorgan at 19:16, 13 January 2013

2013-01-13T19:16:10Z

TimMorgan at 19:29, 5 January 2013

2013-01-05T19:29:53Z

TimMorgan at 19:26, 5 January 2013

2013-01-05T19:26:33Z

TimMorgan at 00:08, 26 June 2012

2012-06-26T00:08:06Z

TimMorgan at 16:00, 16 June 2012

2012-06-16T16:00:24Z

TimMorgan at 15:59, 16 June 2012

2012-06-16T15:59:43Z

TimMorgan: Created page with "==FLOSSHack for Participants== FLOSSHack events are a prefect event for those looking for an hands-on way to learn more about application security. Participants are encourag..."

2012-06-12T04:21:45Z

Created page with "==FLOSSHack for Participants== FLOSSHack events are a prefect event for those looking for an hands-on way to learn more about application security. Participants are encourag..."

New page

==FLOSSHack for Participants==

FLOSSHack events are a prefect 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:

# 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.
# Eager participants get familiar with the target software and begin auditing the application on their own.
# FLOSSHack workshop begins. Participants may join in person or remotely. Workshop sessions may last anywhere from 2 to 4 hours.
## 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.
## 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.
## 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.
## 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.)
## 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).
# 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.

@@ Line 17: / Line 17: @@
 So you think you found a vuln?  Fantastic!  Here's what we need from you for your vulnerability to be counted in the competition:
 * 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.

@@ Line 19: / Line 19: @@
 * 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 bug reports and instances.  For instance, if you found an XSS in 10 pages all from the "<code>...?FOO={evil}</code>" 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.
+* Be reasonable in grouping your findings logically into bug reports.  For instance, if you found an XSS in 10 pages all from the "<code>...?FOO={evil}</code>" 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 ====

← Older revision		Revision as of 19:26, 5 January 2013
Line 11:		Line 11:
	# 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.		# 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:
		+
		+	* 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 bug reports and instances. For instance, if you found an XSS in 10 pages all from the "<code>...?FOO={evil}</code>" 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.

−	~~Remember, FLOSSHack is about '''helping'~~'' ~~secure target software~~, '''~~learning''~~' ~~the art of hacking~~, and ~~of course, having '''fun'''!~~	+	==== 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.

← Older revision		Revision as of 00:08, 26 June 2012
Line 1:		Line 1:
−	~~==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:		[[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:

@@ Line 1: / Line 1: @@
 ==FLOSSHack for Participants==
-FLOSSHack events 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:
+[[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:
 # 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.