Tags for security bugs
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• csteipp
	Nov 20 2014, 11:29 PM

Description

Can I get 4 projects/tags created, so that I can classify some of the most common mediawiki bugs?

Names - description:
websec-inject - This tag is used to group security bugs by their general classification. These bugs allow an attacker to inject their own code or commands into the normal processing. See OWASP Top 10 2013 - A1

websec-xss - This tag is used to group security bugs by their general classification. These bugs allow an attacker to run javascript in another user's browser (Cross-site Scripting / XSS). See OWASP Top 10 2013 - A3

websec-csrf - This tag is used to group security bugs by their general classification. These bugs allow an attacker to cause another user to take actions on the website without their knowledge. See [https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF) | OWASP Top 10 2013 - A8]]

websec-infoleak - This tag is used to group security bugs by their general classification. These bugs allow a user to access information that they shouldn't have access to. See [https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control | OWASP Top 10 2013 - A7]]

Related Objects

Mentioned In: T109968: List #Security subprojects (e.g. Vuln-*) in Phabricator project description

Event Timeline

• csteipp created this task.Nov 20 2014, 11:29 PM

• csteipp raised the priority of this task from to Needs Triage.

• csteipp updated the task description. (Show Details)

• csteipp added a project: Phabricator.

• csteipp changed Security from none to None.

• csteipp subscribed.

• Stype_and_Co.-WMF added a project: acl*security.Nov 20 2014, 11:36 PM

• Stype_and_Co.-WMF subscribed.

seems good to me, will wait till after migration tho :)

I can create them right now, if needed. One thing less.

Er... or maybe not because it would be better to test them next to security issues, just in case. @chasemp is right.

Qgil triaged this task as Medium priority.Nov 20 2014, 11:45 PM

Liuxinyu970226 subscribed.Nov 21 2014, 12:01 AM

After all the side discussions this weekend on IRC, now I don't know what to do with this task.

On one hand, it looks like our Security extension will strip any projects other than "Security" in private tasks.

On the other hand, those projects have absolutely no relation with the fact that a task is private or not, since that condition is established by the Security dropdown.

Since we are going to live with the Security extension and this behavior until further notice, I'd rather make people understand how the system work, while still allowing to tag tasks with projects to those with access to do so. Here we have a real use case: @csteipp wants some organization in private tasks. Note also that some private tasks are made public after fixing the problem, so an indication of to the project(s) a task belongs too would be useful here as well.

JanZerebecki subscribed.Nov 24 2014, 12:59 PM

Qgil edited projects, added Project-Admins; removed Phabricator.Nov 26 2014, 8:33 AM

I'm just wondering if this might ever lead to reporters filing a ticket against a websec-* project and not setting the Security bug checkbox.
But yeah, this would require changing our Security extension behavior first. Until then you might want to go with task summary prefixes? :-/

Aklapper lowered the priority of this task from Medium to Low.Dec 1 2014, 4:44 PM

In T1390#798540, @Aklapper wrote:

I'm just wondering if this might ever lead to reporters filing a ticket against a websec-* project and not setting the Security bug checkbox.
But yeah, this would require changing our Security extension behavior first. Until then you might want to go with task summary prefixes? :-/

We currently have that issue with the "security" project and the "Security-Core/Extensions/Other/General" projects.

What about vuln-xss, vuln-csrf, etc?