> Improper cookie invalidation that could allow an attacker to unset internal global variables.
Those don't count as serious issues? Props to them for making the report public though.
> Improper cookie invalidation that could allow an attacker to unset internal global variables.
Those don't count as serious issues? Props to them for making the report public though.
> CSV files are just text files (the format is defined in RFC 4180) and evaluating formulas is a behavior of only a subset of the applications opening them - it's rather a side effect of the CSV format and not a vulnerability in our products which can export user-created CSVs. This issue should mitigated by the application which would be importing/interpreting data from an external source, as Microsoft Excel does (for example) by showing a warning. In other words, the proper fix should be applied when opening the CSV files, rather then when creating them.
https://sites.google.com/site/bughunteruniversity/nonvuln/cs...
As framed, this is kind of similar to using a Google web tool to edit an XML file, export it and compromise someone using external entity injection. In that context, you're not really compromising Google, and you're not using Google as a medium to automatically compromise many Google users at once. Google is only peripherally involved in the process.
What would qualify for a bounty is code/script execution on a Google host using a CSV file, maybe through something like Google Trends Correlate (https://www.google.com/trends/correlate). Either reflect the CSV contents in a publicly accessible location with a mismatched content-type or leverage an arbitrary file upload error to execute a malicious payload disguised as a CSV on the server. But just exporting a CSV from a Google host is not really a vulnerability in Google.
By the way, for people who are interested in bug bounties, it looks like the page I linked hasn't been updated since 2011. Might want to check it out.
If you work on a web application where users can generate reports that contain input from other users, and a common workflow is for users to download those reports and open them in Excel, they aren't going to be happy if your site is a vector for attacks. Saying "Oh, but it's an attack against your laptop, not against our servers; WONTFIX." is going to be tough to justify.
Iff the user has Excel, and explicitly allows it to run macros in a CSV file. It's already a stretch to call this a phpMyAdmin vulnerability, much less a "medium severity" one.
> > Improper cookie invalidation that could allow an attacker to unset internal global variables.
From the PDF report:
> Note: Because of the large amount of global variables, and the relatively short nature of this assessment, NCC Group was unable to fully determine the impact of this vulnerability.
It might be serious, but they didn't have enough budget to make a proper analysis.
In other words, "This project is too full of potential security holes to find the definite ones."
As for your other comments, there's this "burden of proof" thing.
Performing a full source audit is going to result in sticker shock for all but the most well-funded.