bugcrowd / vulnerability-rating-taxonomy Goto Github PK
View Code? Open in Web Editor NEWBugcrowd’s baseline priority ratings for common security vulnerabilities
Home Page: https://bugcrowd.com/vrt
License: Apache License 2.0
Bugcrowd’s baseline priority ratings for common security vulnerabilities
Home Page: https://bugcrowd.com/vrt
License: Apache License 2.0
Weak password policy is one of those issues that are often by design due to usability concerns and customers tend to accept the risk that comes with it. We do see cases where weak or lack of password policy are unintended which makes corresponding reports valid. However not enforcing strong user passwords is not a vulnerability in the product and should be recommended as P5 - Informative with a few most severe exceptions.
Current state:
1.Insufficient Security Configurability->Weak Password Policy->Complexity, Both Length and Char Type Not Enforced (P3)
2.Insufficient Security Configurability->Weak Password Policy->Complexity, Length Not Enforced (P4)
3.Insufficient Security Configurability->Weak Password Policy->Complexity, Char Type Not Enforced (P4)
Proposed changes:
Insufficient Security Configurability->Weak Password Policy->Complexity Not Enforced (P4)
This equals to no password policy, one character password allowed, e.g. "a".Insufficient Security Configurability->Weak Password Policy->Minimum of 8 Characters Not Enforced (P5)
Insufficient Security Configurability->Weak Password Policy->Char Type Not Enforced (P5)
e.g. "wpwpwpwp".Insufficient Security Configurability->Weak Password Policy->Password of Repeat Characters Allowed (P4)
e.g. "aaaaaaaa".The above names might need some tweaking but in general would mean that issues reporting no password policy (e.g. "a") or only enforcing length (e.g. "aaaaaa", "11111") would be recommended as P4, any other password policy would be marked as P5 Informational.
All feedback is welcome
Recently when I saw this bug category as P3,I raised a couple of bugs.
All of them were changed to P4/P5.
Kindly modify/change the priority in VRT for this bug category to P5 if its not P3.
Insufficient Security Configurability | Weak Password Policy | Complexity, Both Length and Char Type Not Enforced
Dear Bugcrowd,
First of all, I would like to thank your team for opensourcing this project and allowing members of the community to contribute to the development process. I have thought long and hard about the core concept of this project and have come to the conclusion that there are some big changes that I would love to see Bugcrowd make in their approach. I will break down my two major concerns and a minor one into individual sections and try my best to always give some suggestions as to how you might be able to resolve these issues.
This is the biggest point by far, because this is related to the actual idea behind this project. The VRT currently associates a vulnerability class as seen on the OWASP Top 10 list with a severity score. In my opinion, and I have said it many times before in the past (https://twitter.com/EdOverflow/status/931538905668702209), programs should not take this approach when evaluating the bounty amount and sadly this is far too common (I have made this mistake in the past too). Researchers are left disappointed when all of a sudden the program sets a lower priority score for something that the VRT told them was a P2, for instance. This has not only caused confusion within the community (I regularly get DMs about this issue), researchers are starting to falsely state what the issue type is hoping that they will get a higher score.
The priority score should be determined by the impact and what the company's threat model is. Broken Cryptography > Cryptographic Flaw > Incorrect Usage
having access to test data "usually" does not have the same impact as the same issue allowing the hacker to access PII. Therefore my suggestion is that you rethink the core concept of this project and consider redesigning it so that the impact has a direct correlation with the score and not the security vulnerability category. On top of that, it could even help if Bugcrowd added some sort of functionality that enables the program to supply the platform with their threat model and ensure that this influences the score.
Your README.md does state the following, but personally I see this as a way to simply unintentaionally cover up the real issue here:
It is important to remember that while the recommended priority, from P1 to P5 might apply without context, it’s possible that application complexity, bounty brief restrictions or unusual impact could result in a different rating.
As stated earlier, context should be foremost when evaluating an issue.
In my opinion CWE, summarize this concern best: "Prioritizing Weaknesses Based Upon Your Organization's Mission". [1] This brings me to my next section.
After considering the first section, I am hoping that the security categories would be a separate option in the submission process as seen on HackerOne. HackerOne currently uses the Common Weakness Enumeration list in section 2 of the submission form. This has already been suggested to you before in #99, but personally I would like to see this as a separate dropdown option on Bugcrowd, therefore you might need to restructure the current VRT JSON mapping in order to accommodate for this change.
I would like to emphasize the fact from section one again, this option should not directly influence the priority score.
Currently you state the following:
Please open your feedback as an Issue and label it as either a
bug
or anenhancement
.
This might be confusing for some as only members of the Bugcrowd GitHub organization can label issues. For example, I cannot label the following ticket.
In addition, I would suggest increasing the number of labels so that it is easier to refine one's search while looking for previously submitted tickets. You may use https://github.com/securitytxt/security-txt as an example of how this can be done.
With movement/consolidation of subcategories/variants between versions without change of what vulnerabilities map to them, we need a way to easily consume these mapping adjustments. With things such as aggregate counts of VRT classifications between many vulnerabilities, we will want to fall to the current mapping, so a category isn't repeated (with past and present name).
Since Reflected File Download (RFD) is not specifically addressed in the VRT, it calls for a new entry.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Initial priority proposal:
P5 - Based on the social engineering aspect of the attack vector
Potential classifications:
Client Side Injection->Reflected File Download (RFD)
Server Security Misconfiguration->Reflected File Download (RFD)
References:
Bug bounty researcher writeup by David Sopas https://www.davidsopas.com/reflected-file-download-cheat-sheet/
Post by Oren Hafif https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/
All feedback is welcome
Below classification is P3 in VRT
Server Security Misconfiguration | Mail Server Misconfiguration | Missing SPF on Email Domain
Under what scenario will this be marked as P3?
In my experience always this is marked as P4. If it cannot be considered as P3 then cant it be made as P4 in VRT.
Since open redirect vulnerabilities are mainly exploited for phishing and the impact is rather on user trust than direct product security we are considering revising the corresponding VRT category and its general priority.
We need to discuss what value do this type of reports present to the customers and adjust the classification accordingly to provide better transparency for the researchers and consistent triaging guidance.
Current state:
-Unvalidated Redirects and Forwards->Open Redirect->GET-Based (All Users) (P3)
->GET-Based (Authenticated) (P4)
->GET-Based (Unauthenticated) (P4)
Classification and initial priority proposal:
-Merging 'Get-Based...' variants into one P4 priority variant.
Some references to consider:
All feedback is welcome
Since JSON Hijacking is not specifically addressed in the VRT, it calls for a new subcategory.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Initial priority proposals:
Potential classifications:
All feedback is welcome
As per the VRT UXSS is a P4. But there is a feeling that here it is in the context of the security of the web site, and not browser plug-ins / browsers. I mean that when you made the VRT, you probably had in view of vulnerabilities like CVE 2015-0072 (you must put the x-frame-options header at your site to protect).
Please add UXSS (SOP bypass) for browsers and browser plug-ins (looks like this should be P2 or P1). If i can inject js at every site - it seems to be not P4.
Examples:
CVE-2016-5208
CVE-2016-5207
CVE-2016-5205
https://www.blackhat.com/docs/asia-16/materials/asia-16-Baloch-Bypassing-Browser-Security-Policies-For-Fun-And-Profit.pdf
etc..
The VRT breaks down CSRF issues into three classes that are addressed by the entries below:
Cross-Site Request Forgery (CSRF)->Applicaton-Wide (P2)
Cross-Site Request Forgery (CSRF)->Action-Specific->Authenticated Action (null)
Cross-Site Request Forgery (CSRF)->Action-Specific->Unauthenticated Action (null)
This classification seems to be working well since it was released in VRT v1.1. However there is still some room for improvement in the Action-Specific
subcategory that we might consider. Issues like login and logout CSRF are common enough to earn their own entries. Unauthenticated Action
variant might be something we could consider accepted risk in general (that includes cart/basket CSRF issues). We need to discuss our position on login and unauthenticated CSRF and how we want to update the CSRF classification to provide better transparency for the researchers and consistent triaging guidance.
Potential classifications involve removing the Action-Specific
node and moving the variants up to subcategory level:
This solution might not be ideal as the authenticated/unauthenticated subcategories wouldn't have any other variants to choose from:
Cross-Site Request Forgery (CSRF)->Authenticated Action->Logout (P5)
Cross-Site Request Forgery (CSRF)->Unauthenticated Action->Login (P4/P5)
Alternatively adding a separate subcategory independent of the authenticated/unauthenticated entries:
Cross-Site Request Forgery (CSRF)->Login/Logout (P5)
As above but Login CSRF classified as P4:
Cross-Site Request Forgery (CSRF)->Login (P4)
Cross-Site Request Forgery (CSRF)->Logout (P5)
Additionally classifying all unauthenticated CSRF as P5 regardless of the decision to have a P4 login CSRF entry:
Cross-Site Request Forgery (CSRF)->Unauthenticated Action (P5)
All feedback is welcome
Since Binary/DLL Planting/Hijacking is not specifically addressed in the VRT, it calls for a new subcategory.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Initial priority proposal:
P5 - based on the need to satisfy the necessary prerequisites (may be increased case-by-case by context)
Potential categories:
All feedback is welcome
Since missing DNS Certification Authority Authorization (CAA) Resource Record is not specifically addressed in the VRT, it calls for a new entry.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Potential classification:
Server Security Misconfiguration->Misconfigured DNS->Missing Certification Authority Authorization (CAA) Record (P5)
All feedback is welcome
Since the VRT addresses issues where credentials are sent over an unencrypted channel (Broken Authentication and Session Management->Weak Login Function->Over HTTP (P3)
) but does not address login pages served over HTTP that do send credentials over HTTPS, it calls for a new Weak Login Function variant.
Ensuring that credentials are transported over an encrypted channel is not enough protection if the page containing the login form is served over HTTP. The main threat in that kind of a setup is an active MitM attack modifying the login page's source code and stealing the credentials as a result.
We need to discuss how to address this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Initial priority proposal:
P4 - Active MitM required
Potential new variant:
Broken Authentication and Session Management->Weak Login Function->From HTTP to HTTPS
All feedback is welcome
Sensitive Data Exposure->Mixed Content->Sensitive Data Disclosure (P4)
is being commonly confused with regular data disclosure. Requires Being a Man-in-the-Middle (P5)
variant adds to confusion as exposure of various types of data transmitted over HTTP is not currently addressed in the VRT. This calls for 'Mixed Content' subcategory revision and adding a new subcategory addressing insecure data transport.
As Mixed Content is a vulnerability of its own kind it should not cover all HTTP sensitive data transmission, it should strictly apply to HTTPS->HTTP connections. Since active mixed content is blocked by default in modern browsers, the attacker cannot alter the HTTPS host page or access its DOM. The risk is limited to exposing sensitive data over HTTP or spoofing content requested over HTTP.
We need to discuss how to revise 'Mixed Content' subcategory and address various sensitive data transmission over HTTP in order to avoid future confusion, provide better transparency for the researchers and consistent triaging guidance.
Current state:
Sensitive Data Exposure->Mixed Content->Sensitive Data Disclosure P4
Sensitive Data Exposure->Mixed Content->Requires Being a Man-in-the-Middle P5
Potential fix:
Step 1.
A. Renaming ‘Mixed Content’ to ‘Mixed Content (HTTPS To HTTP Connection)’ for clarification
B. Removing current confusing variants and leaving a dedicated Mixed Content subcategory:
Sensitive Data Exposure->Mixed Content (HTTPS To HTTP Connection) (P5)
Simply pointing out Mixed Content should be considered a P5 (active MitM required for HTTP content spoofing). However If there is sensitive data being sent over HTTP, a dedicated Sensitive Data Exposure subcategory should apply.
Step 2.
Creating a dedicated Sensitive Data Exposure->Insecure Data Transport
subcategory in order to address various sensitive data transmission over HTTP.
Potential classifications:
A - Sensitive Data Exposure->Insecure Data Transport (context based)
B - Sensitive Data Exposure->Insecure Data Transport->Sensitive Data (context based)
- Sensitive Data Exposure->Insecure Data Transport->Non-Sensitive Data (P5)
All feedback is welcome
Since Internal IP Disclosure
issue is reported many times, and is not specifically addressed in VRT, I suggest to add it as a new category under Sensitive Data Exposure
.
Initial priority proposal:
Sensitive Data Exposure -> Internal IP Disclosure (P4)
Looking forward for your opinions.
Since Exposed phpinfo is not specifically addressed in the VRT, it calls for a new subcategory/variant.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Priority proposal:
P4
Potential categories:
All feedback is welcome
I suggest that we create a new entry, for issues that report cookies scoped to .target.com
, and effectively being made available to all subdomains. I'd suggest we make two variants
session cookies -> P4 and rewardable
non-session cookies -> P5 and non-rewardable.
The reason this is rewardable for session cookies, is due to the fact that if a subdomain occurs, the attacker can read the session cookie on that subdomain, and effectively take over all logged in accounts that browse that subdomain.
Thoughts?
Since missing DKIM is not specifically addressed in the VRT and is currently triaged as P5 it calls for a new variant.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Priority proposal:
P5 - lack of defense-in-depth mechanism rather than a vulnerability
Potential categories:
All feedback is welcome
It'd be super handy if each entry in the VRT mapped to CWE and had a CVSS base vector attached to, so we can easily map it to other taxonomies.
There are two subcategories in the VRT addressing sensitive tokens in URLs in an inconsistent way. SESSION tokens in URLs over HTTPS are classified as P5 while SENSITIVE tokens in URLs as P4 in any case.
While the risk in case of sensitive tokens in URLs over HTTPS is lower than over HTTP, it is still relevant. HTTPS URLs despite being encrypted for transportation, will often be stored in the destination server's logs, thus exposing sensitive data they contain to anyone who has logs access.
In order to provide better transparency for the researchers and consistent triaging guidance we need to discuss the following:
Potential fixes:
Sensitive Data Exposure->Sensitive Token in URL
subcategory and renaming Broken Authentication and Session Management->Session Token in URL
to Broken Authentication and Session Management->Sensitive Token in URL
(with or without the HTTP/HTTPS variants)Broken Authentication and Session Management->Session Token in URL
subcategory (and potentially adding an HTTPS variant to Sensitive Data Exposure->Sensitive Token in URL
)Broken Authentication and Session Management->Session Token in URL
subcategory and setting its priority to P4, so there's no distinction between HTTP and HTTPS and no inconsistency between subcategories addressing session or sensitive tokens in URLs.All feedback is welcome
Right to Left Override (RTLO for short) is virtually the same vulnerability as a current P5:
Server Security Misconfiguration -> Unsafe File Upload -> File Extension Filter Bypass
The only difference is the methodology used to exploit, but the end result is virtually the same.
I'm proposing we simply append RTLO to the current variant:
From: File Extension Filter Bypass
To: File Extension Filter Bypass/RTLO
Unicode has a special character, U+202e, mainly used for writing and reading of Arabic or Hebrew text. This Unicode character tells computers to display the text that follows it in right-to-left order. This can be used to disguise the names of files such as in File Upload functionality. For example, a file called testFileexe.doc is actually testFiledoc.exe. This occurs because an invisible U+202e character is placed just before “doc.” The file will bypass the upload filter as .doc but will run as .exe
The reason I'd like to add RTLO is because it's a rare finding that's easily forgettable. Adding it to the VRT would give us quick insight into what's being reported. Plus it's not creating a new vulnerability entry so its impact to the VRT is minimal.
Feel free to share any thoughts or concerns, all feedback is welcome.
What about adding the new category Cross-Site Scripting (XSS) / Stored / Non-Admin to Admin?
It affects ONLY Admins, so it does not fit under Cross-Site Scripting (XSS) / Stored / Non-Admin to Anyone.
For example, the one that I found is about documents uploading in a website which allows only admins to see/download these files. The form of the document name was vulnerable, so I could write some javascript code in that form, upload my document and, once an admin would click on the document name in order to download it, the XSS triggered.
I submitted it as Cross-Site Scripting (XSS) / Stored / Self [P5], but then the security staff of the company changed the priority to P4.
Regards,
Alessandro Brucato
Bitsquatting refers to the act of registering domains that are 1-bit off from a legitimate domain in order to capture traffic destined for that domain. But due to corruption an alternate domain is requested instead. A good example of corruption would be an error due to overheating which could cause components to misfire and a single bit to change from a 1 -> 0 or 0 -> 1. For example a victim intending to request bugcrowd.com, may instead request to bugcrows.com or bzgcrowd.com.
Errors caused by component misfiring can be due to overheating, manufacturing defects or electrical problems. In 2015 it was reported that Google's Belgium data center would reach temperatures of 95 degrees during peak hours. Source: https://www.defcon.org/images/defcon-21/dc-21-presentations/Stucke/DEFCON-21-Stucke-DNS-Hazards-Updated.pdf
Attackers are not limited to most popular domains, they can purchase variants of lesser known but widely requested domains such as those made in background of the request/response lifecycle.
A victim requests bugcrowd.com but due to a bit-error makes a request to mugcrowd.com. An attacker owns mugcrowd.com and could return anything he wanted to the victim (e.g. Javascript, Malware, Ads).
Bitsquatting can lead to DNS Cache poisoning if the attackers IP address is cached.
Attacker will be able to see client side request headers and parameter/value pairs
Server Security Misconfiguration -> Bitsquatting (P5)
I'm proposing P5 because, from a bug bounty perspective anything higher is sure to result in reports for domains 1-bit away from the intended domain. Since backend protections exist, demonstrating anything other than a full exploit doesn't prove a company is at risk. If a researcher provides strong evidence of full exploitation, that would easily be a P1, but I'm unsure how that could be communicated via VRT.
The easiest way to stop bitsquatting is to register all available variants of a domain. Since Bitsquatting requires a very high number of requests, it’s only a feasible attack on domains receiving several hundreds of thousands of requests per day. Companies with such high traffic are more likely able to afford this purchase.
ECC - Error Correcting Code is a method of detecting and correcting single-bit memory errors
CRC - Cyclic Redundancy Checks is error detecting code running on a network. All incoming code is flagged and before being used is checked against the internal code. If an error is detected, the code is flagged to and reviewed by a network admin
The VRT does not address lack of password confirmation on 2FA setup. Currently there are three entries addressing lack of password confirmation on critical actions:
Server Security Misconfiguration->Lack of Password Confirmation->Change Email Address (P4)
Server Security Misconfiguration->Lack of Password Confirmation->Change Password (P4)
Server Security Misconfiguration->Lack of Password Confirmation->Delete Account (P4)
Lack of password confirmation on 2FA setup poses some limited security risk, to name one example it could result in the victim being permanently locked out, which has similar impact to the Delete Account
variant. It seems to be a significant enough action to earn its own entry.
We need to discuss how to address this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Initial priority proposal:
P4
Potential classification:
All feedback is welcome
This is a low-impact but sub-optimal behavior for PW reset flows. The scenario is as follows:
The fix would be making sure to invalidate any outstanding PW reset token when the user logs in.
This would be a P5, nested like so:
Insufficient Security Configurability > Weak Password Reset Implementation > Token is Not Invalidated After Login
"Source Code Disclosure" vulnerabilities do not neatly fit into one of the existing vulnerabilities, and come up often enough that I believe they deserve their own title.
I think it should be a subcategory of the "Sensitive Data Disclosure" category.
The vulnerability can often lead to the disclosure of secrets, comments, configuration settings, employee information, and internal system information, as well as sometimes allowing further vulnerabilities to be more easily discovered.
I'm not sure on the default priority, it could be from a 2 to a 4. It is more sensitive than "Descriptive Stack Trace" which is a 5, as the source code implies a stack trace and more.
There is a CWE for this, CWE-540: https://cwe.mitre.org/data/definitions/540.html
Thank you.
Recently i reported a CSV Injection Vulnerability to a Program on Bugcrowd, but the changed the State of the Report to Won't Fix as per the Bugcrowd Vulnerability Rating Taxonomy, but if you dig deep you can gain full Access to Victim Machine through this vulnerability, What an attacker can do is he can generate a payload from Metasploit which will create a reverse shell connection back to the attacker's machine. and Attacker can inject that payload into the csv or xls file because the Web App is not properly sanitizing the fields and when the user will execute this file the attacker will be able to gain full access over the system.
I have linked the complete video POC of this issue.
Since server-side plaintext credentials storage is not specifically addressed in the VRT, it calls for a new entry.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Initial priority proposal:
P4 - Best practice due to requirement of chaining with a high/critical risk issue, but at the same time posing hight impact if successfully exploited.
Potential classifications:
All feedback is welcome
Since misconfigured DNS zone transfer is not specifically addressed in the VRT, it calls for a new entry.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Potential classification:
Server Security Misconfiguration->Misconfigured DNS->Sensitive Zone Transfer (P4)
Server Security Misconfiguration->Misconfigured DNS->Non-Sensitive Zone Transfer (P5)
All feedback is welcome
I'd like to revisit #33 for CWE now that CVSS (#86) is in.
CWE is an alternate taxonomy that should map to our VRT relatively cleanly, as demonstrated in #33. This will be useful for customers, and for mapping to other data, for example: http://cwe.mitre.org/top25/.
Should be a new file, or do we want to co-opt the CVSS mapping json?
Banner disclosure issues (aka Banner Grabbing) are commonly seen as accepted risk by the customers and are listed under "Common "Non-qualifying" Submission Types" in our Standard Disclosure Terms, but are not specifically addressed in the VRT.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Potential classifications:
All feedback is welcome
OWASP top 10 2017 is planned to be released in November. While two of the top ten categories are still being chosen we can already say with a high degree of certainty that IDOR and Missing Function Level Access Control will be replaced by A4-Broken Access Control. Since the VRT is going to be released around the same time we can already take some steps to adjust our mapping.
Potential category adjustments:
Missing Function Level Access Control
category to Broken Access Control (BAC)
while keeping all its children.Insecure Direct Object References (IDOR) (null)
category should be moved like so: Broken Access Control (BAC)->Insecure Direct Object References (IDOR) (null)
All feedback is welcome
My proposed change is to add a entry for "Broken Authentication and Session Management"->"Second Factor Authentication Bypass". I also feel as if a P2~P3 priority aligns well with that entry.
As a follow-up to the question/comments on: #87
I am not convinced by P2 for bypassing second factor only, after all being able to do so is similar to not having 2FA enabled in terms of security impact, at least in most cases. The difference being the account owner trusting a broken defense-in-depth mechanism.
For some cases, I would agree with the statements made here! However, when second-factor is leveraged, you are changing what you are authenticating. For example, a single factor authN system is just authN'ing a specific user. In a 2FA system, you could be authN'ing a specific user in possession of a specific device. That device binding could be critical to the system's security (e.g. legacy systems could have a very weak password authN mechanism so the admins of that system rely on 2FA from managed mobile devices). In general, I would say most second factor authN mechanisms are more trustworthy than password authN (Which is why I'm currently leaning towards a P2~P3 instead of just a "Varies" priority).To reduce them to "defense-in-depth" seems like a mischaracterization though.
Looks like the Insufficient Security Configurability->Weak 2FA Implementation subcategory would be the entry of choice here, granted it does not have an assigned priority, but context based seems to be appropriate.
That category seems more aligned with bad 2FA design decisions instead of a vulnerability that allows the bypass of a particular authentication step. Thoughts?
Also, re-stating my original questions from the PR in-case others want to weigh in:
It may be worthwhile to update the P1 "Authentication Bypass" item to something like "Complete Authentication Bypass".
I went with "Second Factor Authentication Bypass", but I think "Second Step Authentication Bypass" or "Partial Authentication Bypass" may apply more generally.
Since insecure data transport class of issues is addressed across multiple categories (some entries in progress) and Insecure Data Transport
top category’s main purpose is to address SSL Pinning in mobile devices, it’s neither proper classification for mobile related issues, nor is the category otherwise beneficial or prospective.
We need to discuss the best classification for this type of issues to ensure that we deliver a concise taxonomy.
Current state:
-Insecure Data Transport->SSL Certificate Pinning
Potential SSL certificate pinning classification after removing Insecure Data Transport
top category:
-Mobile Security Misconfiguration->SSL Certificate Pinning
All feedback is welcome
We added the script that checks for deprecated nodes here #31, but did not yet add the process to the CI
Tapjacking can be a serious vulnerability, but falls within a very limited scope with protections both client and server side. Our entry should communicate a low score consistent with the scope and protections.
Tapjacking is a vulnerability exclusive to Android devices & certain Android OS versions. The vulnerability allows an attacker to place a transparent frame over the victims device. While the victim believes he is interacting with the UI he sees, his clicks are being transmitted to the device performing actions predetermined by the attacker.
An attacker could trick a victim into enabling/disabling specific settings or in a severe case, trick the victim into downloading malware.
Potential Classification:
Mobile App Misconfiguration -> TapJacking -> Sensitive Action (P5)
Mobile App Misconfiguration -> TapJacking (P5)
Mobile App Misconfiguration is not currently a category, so this would mean adding a new one.
As you can see there's a proposed classification without "Sensitive Action." This is because, as far as I can tell, the severity is limited by the attackers skill & intent. Therefore researchers won't need to add a working POC, only demonstrate the protective flags are not in place.
All feedback is welcome.
The VRT addresses distinct insecure token/credentials transmission issues across multiple categories, but does not address various types of sensitive data, to name a few: PCI information, PII, PHI etc. that might be transmitted using several insecure protocols.
Current entries:
Broken Authentication and Session Management->Weak Login Function->Over HTTP (P3)
Broken Authentication and Session Management->Weak Registration Implementation->Over HTTP (P4)
Sensitive Data Exposure->Token Leakage via Referer->Over HTTP (P4)
Sensitive Data Exposure->Weak Password Reset Implementation->Password Reset Token Sent Over HTTP (P4)
Sensitive Data Exposure->Mixed Content (HTTPS Sourcing HTTP) (P5)
Network Security Misconfiguration->Telnet Enabled->Credentials Required (P4)
Since the VRT does not address unencrypted transmission of various types of sensitive data, it calls for a new catch all entry.
Initial priority proposal:
null - context based, depending on the type of data and transit configuration
Potential classifications:
All feedback is welcome
Hey team,
After seeing many path disclosure submissions, and validating them often(if not always) as P5 due to the low risk of the issue, I believe it's time to have an official entry in our VRT, as it'll help to provide better transparency for the researchers and as well as to clients. It should be also noted that it'd definitely improve our triage/validation workflow.
My suggested variant is: Sensitive Data Exposure - Visible Detailed Error Page - Full Path Disclosure P5
I'd love to hear others thoughts on this.
External Authentication Injection issues are mainly exploited for phishing and the impact is rather on user trust than direct product security. Furthermore, all major browsers (latest versions) mitigate somehow this kind of issues e.g. by alerting the user about the potential phishing risk:
For this reasons I believe this kind of vulnerabilities should be seen more like an issue that should be prevented by the browser rather than the web application. So my proposal is to downgrade its general priority to P5.
All feedback is more than welcome!
Hey Folks,
There are currently two priority levels for Token Leakage via Referer
, the first is P4 when the token is being sent over HTTP, the second is a P5 when the token is sent over HTTPS. I think these should be consolidated into a P4 as the risk here is that the token is going to end up in the logs of the destination server.
Let me know your thoughts.
Best Regards,
Justin Kennedy
Visible descriptive stack traces are currently triaged as P5, however are not specifically addressed in the VRT. Since this type of issues have been falling under 'Sensitive Data Exposure->Visible Detailed Error Page' which is context based and does not have an assigned priority it calls for a new subcategory/variant.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Initial priority proposal:
P5 - This issue type is listed under 'Common "Non-qualifying" Submission Types' in our Standard Disclosure Terms
Potential categories:
All feedback is welcome
Hi,
I think in some ways clickjacking can be dangers.
If someone finds chains bug such as missing X-FRAME-OPTION + Self XSS then an attacker can use it to do XSS on a victim via clickjacking.
I found such thing on Google, see my blog post and youtube video.
http://sasi2103.blogspot.co.il/
Cheers,
Sasi
Visible detailed debug (not error) page is not specifically addressed in the VRT. Since this type of issues have been falling under 'Sensitive Data Exposure->Visible Detailed Error Page' the naming has been causing some confusion.
We need to discuss if we need to revise current subcategory naming or add a new subcategory in order to provide better transparency for the researchers and consistent triaging guidance.
Current state:
Sensitive Data Exposure->Visible Detailed Error Page (null - context based)
Potential classification:
All feedback is welcome
Broken Authentication and Session Management->Authentication Bypass
is often confused with privilege escalation aka authorization bypass. That is due to the terminology used in the variants which is generally associated in the industry with privilege escalation and the high default priorities:
Broken Authentication and Session Management->Authentication Bypass->Vertical (P1)
Broken Authentication and Session Management->Authentication Bypass->Horizontal (P2)
We need to answer the following questions:
Potential solution:
Rating authentication bypass aka account takeover at P1 as a general rule, regardless of the affected accounts being admin or user level:
Broken Authentication and Session Management->Authentication Bypass (P1)
Adding privilege escalation entry with or without the vertical/horizontal variants. In both cases despite the vertical variant usually having higher impact it is not granted that it is P1 as it is not granted for its horizontal counterpart to be P2. Context based seems to be the most appropriate choice as it is with the related IDOR:
a. Broken Authentication and Session Management->Privilege escalation (null)
b. Broken Authentication and Session Management->Privilege escalation->Vertical (null)
Broken Authentication and Session Management->Privilege escalation->Horizontal (null)
All feedback is welcome
DBMS misconfiguration issues are not specifically addressed in the VRT. In particular classifying post SQL Injection privilege elevation would be a beneficial VRT enhancement. Excessively privileged current DBMS session user can amplify the consequences of a SQLi vulnerability leading to RCE etc. SQLi being a prerequisite limits the risk significantly, nonetheless such issues should be identified as part of a crowdsourced security assessment.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Potential classification:
Server Security Misconfiguration->Database Management System (DBMS) Misconfiguration->Excessively Privileged User / DBA (P4)
All feedback is welcome
Please refer to this technical write-up on "Broken Link Hijacking" (BLH): https://edoverflow.com/2017/broken-link-hijacking/
BLH can be broken down into two main categories: Stored and reflected.
The different (sub)categories can be classified as follows:
This one I am not too sure about, since it really depends on how convincing the attack is. If the link is the main installation button on the homepage it is going to cause more trouble than a little broken Facebook link on a company's "About" page.
This is essentially stored XSS. The attacker's malicious code is stored in the page. This should be rated the same as stored XSS:
This would mainly fall under:
This category depends entirely on the content being served, but for the most part I imagine this would belong to:
This is the same as reflected XSS.
Since Cross Site Script Inclusion (XSSI) is not specifically addressed in the VRT, it calls for a new entry.
We need to discuss the best classification for this type of issues to provide better transparency for the researchers and consistent triaging guidance.
Initial priority proposal:
null - PoC and context based. The victim has to visit a malicious website, similar as in case of CSRF, but in case of XSSI instead of a state changing action being executed on behalf of the victim, it is going to be sensitive data belonging to the victim being leaked.
Potential classifications:
Sensitive Data Exposure->Cross Site Script Inclusion (XSSI)
All feedback is welcome
The VRT does not address insecure file/code downloads, that is any executable content being provided/downloaded over an unencrypted channel without a secure integrity check. This poses the risk of trusted origin content being spoofed in transit causing evil code execution on client-side.
If downloads are done over an unencrypted channel, which might be a performance choice, there should be an integrity check mechanism provided over an encrypted channel, e.g. checksums served over HTTPS.
Potential classifications under: Server Security Misconfiguration
, Insufficient Security Configurability
, Client Side Injection
or possibly bringing back Insecure Data Transport
:
Category?->Insecure Download->No Encrypted Integrity Check (P4)
Category?->Insecure Download->Encrypted Integrity Check (P5)
(Side note: there's a server-side variation that is addressed by CWE-494)
All feedback is welcome
Noticed the top-level "SQL Injection" does not have a priority set, while the 2 subcategories (Blind and Error-based) are both P1.
Should probably either set P1 on the top-level category or add a new subcategory for SQL injection when attacker can get output directly.
If going with the 2nd option, not sure what you'd call it, maybe "SQL Injection - UNION Based"?
'Insecure Data Storage' category seems to have some redundancy that could be eliminated:
Insecure Data Storage->Credentials Stored Unencrypted->On External Storage
Insecure Data Storage->Credentials Stored Unencrypted->On Internal Storage
Insecure Data Storage->Sensitive Application Data Stored Unencrypted->On External Storage
Insecure Data Storage->Sensitive Application Data Stored Unencrypted->On Internal Storage
'Credentials Stored Unencrypted' and 'Sensitive Application Data Stored Unencrypted' subcategories having identical variants could be replaced by 'Secrets Stored Unencrypted'
Insecure Data Storage->Secrets Stored Unencrypted->On External Storage
Insecure Data Storage->Secrets Stored Unencrypted->On Internal Storage
In addition to that let's look into Insecure Data Storage->Insecure Data Storage->Password (P2)
as the classification and purpose of this entry seem to be unclear.
All feedback is welcome
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.