His question seemed pretty clear to me. As indicated in the article he
linked to, Google apparently raised their bounty/reward. He's asking if
something happened to one of their products to cause that, or if they're
just paranoid (and maybe expecting something to happen to one of their
I would be interested what bounties they would pay
for operation Аврора or for a botnet of say 1M host.
Reward amounts are public; for example, here are the rules for the web
app program:
http://www.google.com/about/appsecurity/reward-program/
Neither malware on user machines nor attacking
OGMMM WTFF 0DAY XSS
Sorry, getting a bit tired of these.
Well, the world is changing. You can probably do a lot more direct damage
with a (legit) XSS in a high-value site than with a local privilege
escalation in sudo.
XSS reports are less actionable for the average reader, but full
This is fairly well-known, I think; for example, there's a mention of this
here (search for appspot.com):
http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html
I think it's also covered in The Tangled Web; it's also why you see
domains such as blogspot.com and appspot.com in
CVSS2 define a standard XSS ~4.3/10, more critical are CSRF ~6.8 or Open
Redirect ~5.8
head explodes
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia -
I guess this may be somewhat amusing...
As you probably know, most browser vendors have fixed the ability to
enumerate your browsing history through the CSS :visited
pseudo-selector. The fix severely constraints the styling possible for
visited links, and hides it from APIs such as
Total word count: ~1065
Words that provide relevant information about the bug: ~95
/mz
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Attack exactly overload web sites presented in endless loop of redirects. As
I showed in all cases of Looped DoS vulnerabilities in web sites and web
applications, which I wrote about during 2008 (when I created this type of
attacks) - 2013.
You do realize that any browser can be made to
I.e. this is 21 times / infinite times more effective for attack.
Not really, in terms of the bandwidth you can use up / the number of
requests you can create. You're essentially trading this:
for (var i = 0; i whatever; i++) {
var x = new XMLHttpRequest(); /* or new Image() or whatever */
for doing this features in httpd.conf you can use AllowOverride None instead
of AllowOverride all
AllowSymlinks is a red herring here (hardlinks should do, unless you
have stuff partitioned in a very thoughtful way, which most don't),
similarly to suexec.
In general, sharing web hosting
Dearly beloved,
So, for one reason or another, the IJG jpeg library has gained some
notoriety as one of the most robust pieces of complex,
security-critical C code. Despite countless fuzzing efforts, I don't
recall any reports of serious vulnerabilities at least since the
release of jpeg6b in
What is your exact concern?
One should obviously not enter their Facebook credentials while the
address bar shows darksecurity.de; after all, instead of framing
Facebook, you could just create a fake login form that looks just like
theirs.
Clickjacking is a distinct concern, but generally only
That page allows drag-and-drop of the user's name. If you can convince the
user
to select his name with a triple-click and then do a drag-and-drop of that
name to
some place outside the iframe, you can find out his name, so I'd say it's a
privacy
leak.
I had something to do with Chrome,
But I wouldn't consider it a failing on part of the targeted website -
you'd need to put essentially everything behind XFO to fix this
problem on application level, which is not feasible for a good number
of websites (including FB, because they have a variety of gadgets that
are meant to be
Doesn't Google always send JSON with Content-Disposition: attachment or so
because of that?
One of the reasons (there's also content sniffing, etc). But then,
consider view-source:, too - you can use it in Firefox to render the
source of a HTML page in a frame (Chrome no longer lets you use
Looks like root and intermediate certificate hashes to me
I was guessing it was hashes to either one pre-compiled exploit with two
architectures
No, if you look closely, it's pretty clear that it's a hash of
Gaurang's upcoming novel. A touching story of love between a vampire
and a small-town
The only reasonable way to 'exploit' the bug is using youtube as a
personal storage uploading non-video files to your own profile: so what?
That would require a way to retrieve the stored data, which - as I
understand - isn't possible here (although the report seems a bit
hard-to-parse). From
If you were evil, you could upload huge blobs and just take up space on the
google servers.
Keep in mind that the upload functionality is there legitimately: you
can upload gigabytes of data to Youtube, Drive, Gmail, etc.
/mz
___
Full-Disclosure -
Nicholas,
I remember my early years in the infosec community - and sadly, so do
some of the more seasoned readers of this list :-) Back then, I
thought that the only thing that mattered is the ability to find bugs.
But after some 18 years in the industry, I now know that there's an
even more
Zakewski,
Thank you for your e-mail. I welcome all opinions, that are backed up by
evidences.
I am not just a security researcher, I am also an academic in the field and
lecturer.
All right :-) Thank you for the overview of CIA triad. I don't think
there's a good probability that our
Oh, wow :-)
To put things in perspective, it probably helps to understand that
virtually all video hosting sites perform batch, queue-based
conversions of uploaded content. There is a good reason for this
design: video conversions are extremely CPU-intensive - and an
orderly, capped-throughput
As a professional penetration tester, [...]
The JSON service responds to GET requests , and there is a good chance that
the service is also vulnerable to JSON Hijacking attacks.
That's... not how XSSI works.
To have a script inclusion vulnerability, you need to have a vanilla
GET response
A hacker exploits a JSON (javascript) object that has information of interest
for example holding some values for cookies. A lot of times that exploits the
same policy origin. The JSON object returned from a server can be forged over
writing javascript function that create the object. This
Is this treated with the same way that says that Remote File Inclusion is not
a security issue ?
I'm not sure how RFI came into play on this thread - the original
report wasn't about RFI.
I don't have an agenda here; I'm just trying to get to the bottom of
it and make sure that we converge on
The thread read Google vulnerabilities with PoC. From my understanding it
was a RFI vulnerability on YouTube, and I voiced my support that this is a
vulnerability.
I don't think this is accurate, at least based on the standard
definition of RFI: a server-side scripting language - usually
201 - 225 of 225 matches
Mail list logo
