The article has a stupid premise (I think intended for trolling) but a
valid point.

The real point here is that a big chunk of the domain of appsec does
not define "vulnerability" in the same way network penetration testing
does. Most appsec tools/vendors paint with a broader brush of defects.
And, because there are so many, they rarely focus on penetration of a
single one. Additionally, penetration does not directly help with
remediation, so many chose to spend their time elsewhere.

So many appsec tools are noisy, and generate "findings" that are
basically defects that may or may not have any security implications.
Like HTTPONLY and =SECURE bits set on cookies. At WhiteHat we call
these "best practices": they may or may not impact the security
posture of your application (and they may have other implications,
positive and negative).

If it isn't exploitable, or leaking confidential information - I have
trouble calling it a vulnerability. Many appsec vendors try to work
around their inherent weakness here by having some form of a
likelihood or "confidence" score associated with sub-par findings.
This weakness aside, we have to start somewhere and one-time network
pentests aren't cutting it.

People focused exclusively on penetration may really know a few new
SQLi exploitation tricks well. But for every exploitable SQLi they
find in an enterprise they probably only miss 1,000 more SQLi in 500
forms they didn't touch....

Arian Evans

On Fri, Jul 8, 2011 at 1:59 AM, Rob Fuller jd.mubix@gmail.com wrote:

Unlike HttpOnly, missing the "Secure" flag on cookies in SSL apps is not a minor problem. You almost might as well not do HTTPS at all if you're not going to get that detail right.

On Jul 8, 2011, at 3:42 PM, Arian J. Evans wrote:

Thomas Ptacek // matasano security // founder, product manager
reach me direct: 888-677-0666 x7805

"The truth will set you free. But not until it is finished with you."

Yes, but that's completely unrelated to the "network" vs "application"
divide. For every web app pentester complaining about OPTIONS, there
is a network pentester complaining about hosts responding to ICMP echo
requests.

As far as that topic goes, however... I don't think it's a good use of
pentester's time (and customer's money) to conduct a full compromise;
but the role of a pentester is to interpret every vulnerability in
terms of its actual impact on the tested platform: that's the value
they add on top of automated tools.

Not every non-httponly cookie, and not every password form without
autocomplete=off, is a plausible security risk. It's OK to denote a
variety of configuration remarks and recommendations in a separate
section, but I do feel that it's cheating to use them as
vulnerabilities to pad the report. But again, that's common sense, as
you note.

/mz

Hi Arian,

I don't really have anything to add to the original topic here, but I
do take issue with this:

If an application fails to use the secure flag, a moderately simple
MitM attack is all that it takes to hijack a session.  This is true
even if you don't even leave port 80 open.

HttpOnly is, however, just a weak mitigation strategy, IMO.

Regards,
tim

It wasn't intended to troll. If the premise is stupid than I guess my perspective is just that. To each their own.

Tools aside, I've noticed greater focus on a smaller amount of vulnerabilities within the NetSec group "that I know". Look at the article and the comments I've made to get the whole picture. Or don't. Meh.

Just please remember, it is a perspective piece. My opinion. My view.

~cktricky's mobile lifeline

On Jul 8, 2011, at 4:42 PM, "Arian J. Evans" arian.evans@anachronic.com wrote:

On Fri, Jul 8, 2011 at 5:00 PM, Thomas Ptacek thomas@matasano.com wrote:

Well, I respectfully disagree Tom.

1. First - nobody gets Sony'd from cookie !=secure. If you go through
   the WASC and CWE attack and weakness nodes I can think of about 40
   that could get you Lulzed; I'd call those major, and stacking this up
   is minor in comparison.

2. Secondly - very few cookies (of the total number of cookies set on
   the Internets) contain sensitive info and require confidentiality.
   (and thus =secure)

3. Thirdishly - if you are using SSL, then this is a defense-in-depth
   best practice, and only provides protection for broken browsers or
   mixed-content mistake.

4. Fourthedly - Most businesses will tolerate cookie leakage before a
   broken application, because of -

5. Fifthously - Slapping =secure on cookies randomly will break
   legitimate features of many applications, whether or not there is any
   security benefit/attack surface reduction

I know security consultants love fluffy report filler. If you charge
your clients premium prices for one-time pen-tests - then customers
tend to feel like they pay by the pound for report size, so you stuff
everything you can in there and make it all sound as terribly
important as possible. However IMHO this is not very useful at moving
the software security bar in large enterprises, and definitely doesn't
scale...at all.

I also think the elitist security attitude towards software
development e.g. -"if you ain't gonna get these little bits right you
might as well pack up and go home" which sounds like "you're an idiot,
developer" are misguided - and may be a reason why some security folks
have a tough time getting traction in organizations regarding solving
software security. That's one of the reasons Jeremiah and I make a
point of going to developer conferences. It's smart to stay close to
the people living with the problem you're trying to solve.

$0.02,

Arian Evans
Software Security Solutions Chef

We are absolutely agreeing. I was not speaking to individual
selection bias in testing.

I was specifically speaking to the problem with appsec tools like Fortify
360 that spray out thousands to hundreds of thousands of "defects and
confusing things with possible security implications" and security folks
who don't understand them yet call those "vulnerabilities"

That is the broad defect!=(exploitable_vuln|security_implication) brush
I was speaking of.

Excellent points as always Michal,

Arian Evans

On Fri, Jul 8, 2011 at 5:24 PM, Michal Zalewski lcamtuf@coredump.cx wrote:

The savvy reader will note that while #2 makes a valid point, #1, #3, #4, #5, and everything after it do something other than make valid points.

On Jul 8, 2011, at 5:49 PM, Arian J. Evans wrote:

Thomas Ptacek // matasano security // founder, product manager
reach me direct: 888-677-0666 x7805

"The truth will set you free. But not until it is finished with you."

I can see #1 being legitimately debatable. I do not see how #3-#5 are
debatable. I would like more detail if you find I am in error.

#3) What does =secure provide, inside a valid SSL tunnel, besides
protection against broken browsers or mixed domain content?

#4) Let me clarify - most retail and some other types of businesses
will tolerate !=secure before they will tolerate functional outage.
Do you disagree?

(insert early WAF shelfware stories here)

#5) If you have legitimate, non-confidential cookie usage (like most
web apps) and you have legitimate, non-transport encrypted traffic
(like many if not most web apps) then you will break things
arbitrarily slapping =secure on them, as I have seen both recommended
and done.

I am guessing if we disagree you are thinking of something
situation-specific e.g.- sensitive financial apps with a singular
session and/or auth cookie.

I still humbly submit that most organizations have thousands of XSS
and SQLi (amongst other types of directly exploitable syntax-attack
exposures) and until you help them fix those you're wasting their time
with this. And, of course, for many apps and cookies there's no reason
to care about =secure.

But I digress,

Arian Evans
Software Security Stuff

On Fri, Jul 8, 2011 at 5:57 PM, Thomas Ptacek thomas@matasano.com wrote:

I agree that SQLI is much more important than the Secure flag. I was prompted to comment only because of the equivalence implied between Secure and HttpOnly.

On Jul 8, 2011, at 6:20 PM, Arian J. Evans wrote:

Thomas Ptacek // matasano security // founder, product manager
reach me direct: 888-677-0666 x7805

"The truth will set you free. But not until it is finished with you."