[Owasp-leaders] Session Variable Overloading

psiinon psiinon at gmail.com
Sat Oct 1 04:57:38 EDT 2011


I think this discussion has actually been very useful, and I think its clear
that names are important.
I also agree that we shouldnt try to rename things that are in common use.
However I also hope that OWASP should be seen as a more authoritative guide
to application security than Wikipedia;)
I'm going to respectfully disagree with Marco: overloading is a concept that
developers understand, and its not necessarily good or bad.
If a dev came to me with a class with one method overloaded 100 times I'd
say that was bad :)
I also think that "cross site" isnt necessarily bad, and neither is
"scripting". "Cross site scripting" on the other hand...

I also think that we've been confusing 2 different aspects:
Vulnerabilities are (typically) issues with the architecture, design or
implementation, and should therefore be named in developer terms.
Attacks are ways of detecting or abusing vulnerabilities, and should
therefore be named in pentester terms.
These are correctly separated in the wiki.

So, my revised naming suggestions are ...

Session Attribute Overloading (thanks Stefano) is a _vulnerability_ where a
session attribute is used in different ways.
It is a subtype of Session Management Vulnerability.
It does not cover timing issues - there are different (but related)
vulnerabilities. Possibly Temporal Session Race Conditions?
Session Puzzling is an _attack_ that can be used to detect Session Attribute
Overloading and TSRCs.

Cue next bun-fight ;)

Simon

On Wed, Sep 28, 2011 at 2:02 AM, Marco M. Morana
<marco.m.morana at gmail.com>wrote:

> Indeed, Mark might remember why I wrote this also..
> http://securesoftware.blogspot.com/2005/12/threat-vulnerabilities-classification.html
>
> Amazing how staff that goes around comes around :)
>
> Marco M.
>
> -----Original Message-----
> From: owasp-leaders-bounces at lists.owasp.org [mailto:
> owasp-leaders-bounces at lists.owasp.org] On Behalf Of Mark Curphey
> Sent: Tuesday, September 27, 2011 10:49 AM
> To: Stefano Di Paola
> Cc: owasp-leaders at lists.owasp.org; Shay Chen
> Subject: Re: [Owasp-leaders] Session Variable Overloading
>
> I once worked on a naming scheme / taxonomy and in short all discussions
> were like this. I stumbled across this definitive (IMHO) paper by Matt
> Bishop and promptly told myself I would never bother again :-)
>
>
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.76.7742&rep=rep1&type=pdf
>
> Curphey bugging out (pun intended)
>
> Sent from my iPhone
>
> On Sep 27, 2011, at 6:49 AM, Stefano Di Paola <
> stefano.dipaola at mindedsecurity.com> wrote:
>
> > Several topics here...
> >
> > 1.
> > @blaufish_ pointed out that there's already a previous attempt to
> > formalize similar session issues (2006-2007).
> > http://en.wikipedia.org/wiki/Session_poisoning
> > http://segfaultlabs.com/pdf/php-session-security.pdf
> >
> > So, even if we already considered that is not a "new issue" I think we
> simply should name it under that
> > category of vulnerabilities.
> > It's our fault if we didn't write about it before.
> >
> > 2.
> > My actual concern about naming, is because OWASP wiki has difficulties in
> keeping congruent names among the projects.
> > In particular testing guide, top ten, build and so on.
> >
> >
> > 3.
> > About OWASP 4 devs, I agree, since testers are more flexible with naming
> conventions.
> > That said, I don't like when someone says "don't name anything else
> because there already are too many names out there".
> >
> > I think that formalization of issues is important since without it devs
> cannot defend against any of them.
> > In my experience (past dev and actual sw sec guy) devs _are_ nitpickers.
> >
> http://www.makinggoodsoftware.com/2009/07/07/5-top-non-technical-mistakes-made-by-programmers/
> >
> http://www.makinggoodsoftware.com/2010/05/27/10-things-they-never-teach-in-college-about-programming/
> > Classic answer is "that is not in the [security|best practice|whatever]
> guidelines.".
> >
> > Because of that we have to be quite precise in definition but if there's
> no agreement in how an issue is called, we have to use the first definition
> and name.
> >
> > What do we want to say to scientists? you can't name theorems, flowers,
> etc with your names cause you're attention whores?
> > At least we are trying to be in topic with the issue.. :P
> >
> > 4.
> > not to be read. it's just a
> > <rant>
> > The fact that groups of people sees other groups as dumbassess is not an
> excuse. It's just classism.
> >
> https://lh3.googleusercontent.com/-gRXpwT6i1ho/TkL8Hq3vd8I/AAAAAAAAiEI/WqeegTl_0mU/TechSeenByTech.png
> >
> > Being humble is the solution.
> > ^
> > It's more about a social analysis at the moment but I'm going OT, I know
> :),
> > so, please, forgive the </rant> :)
> >
> >
> > Il giorno lun, 26/09/2011 alle 10.40 -0700, Mark Curphey ha scritto:
> >> I don't have a huge amount of passion for the specific issue but as
> >> always an opinion ;-)
> >>
> >>
> >> If you look at my slides 38 to 41 of my talk last
> >> week
> http://www.slideshare.net/mcurphey/curphey-appsecusa-community-the-killer-applicationit was about making sure that security is aligned to development. In my day
> job I am a product owner in a scrum model. I usually have my test lead run
> our bug triages but if I attended a bug triage and the bug was called
> Session Smuggling I would ask the team to go and normalize it's naming. We
> require clear and concise naming of defects. For a long time the security
> industry has had a fascination in "creative" naming and I think smuggling
> fits right in there. I totally get how that might align well to security
> where people operate with handles etc (again real names in my systems or the
> item doesn't even get looked at) but I think OWASP needs to optimize for
> developers and not security people. At the end of the day if an issue like
> this is found it will need to be pushed to a bug tracking system for fixing
> and so making sure its in the most effective format to get prioritized is
> key.
> >>
> >>
> >> When I first saw the name I thought of an overloaded method and the
> >> fact a session token was doing something the original method
> >> signature didn't initially intend, hence why it was overloaded.
> >>
> >>
> >> Just my 2 cents....
> >>
> >>
> >>
> >>
> >> On Mon, Sep 26, 2011 at 8:38 AM, Stefano Di Paola <stefano at owasp.org>
> >> wrote:
> >>        Probably I'm not in the mood of mind reading but..what do you
> >>        mean?
> >>
> >>        Choosing the naming convention by OWASP is different from
> >>        naming an
> >>        issue by an "unbiased company" just for fame.
> >>
> >>        In this case I was trying to tell that "Session variable
> >>        overloading",
> >>        even if kind of ok for devs, it's probably not really fitting
> >>        with the
> >>        issue by itself.
> >>
> >>        Imho of course and waiting to hear from you different thoughts
> >>
> >>        Cheers,
> >>        Stefano
> >>
> >>        Il giorno lun, 26/09/2011 alle 08.06 -0700, Mark Curphey ha
> >>        scritto:
> >>
> >>>
> >>
> http://www.curphey.com/2010/04/security-bullshit-21-vulnerability-naming/
> >>>
> >>>
> >>> :-)
> >>>
> >>>
> >>> My personal opinion is OWASP should optimize around common
> >>        development
> >>> practices.
> >>
> >>> I am on iPhone and no flash to view slideshare but at end of
> >>        this deck
> >>> is the alignment slides
> >>>
> >>
> http://www.curphey.com/2011/09/curphey-owasp-appsec-usa-2001-slides/
> >>> from last week.
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Sep 26, 2011, at 7:52 AM, psiinon <psiinon at gmail.com>
> >>        wrote:
> >>>
> >>>
> >>>
> >>>> Hi Stefano,
> >>>>
> >>>> I dont think discussing the name is nitpicking - the right
> >>        name is
> >>>> important.
> >>>> I called it Session Variable Overloading as thats how I
> >>        see it from
> >>>> a developers perspective.
> >>>> I think that Session Puzzling and Session Smuggling make
> >>        more sense
> >>>> from an attackers perspective.
> >>>> In that respect none of them are right or wrong :)
> >>>>
> >>>> Can anyone come up with a name that makes sense from both
> >>>> perspectives??
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Simon
> >>>>
> >>>>
> >>>> On Mon, Sep 26, 2011 at 3:42 PM, Stefano Di Paola
> >>>> <stefano at owasp.org> wrote:
> >>>>        hey Psiinon,
> >>>>        thanks for the links and the OWASP page since this
> >>        kind of
> >>>>        attack is
> >>>>        definitely worth writing.
> >>>>        I like the name "Session puzzling" since it is
> >>        more than
> >>>>        overloading,
> >>>>        though, I can understand the "puzzling" part is
> >>        less
> >>>>        understandable from
> >>>>        a dev point of view.
> >>>>        At this point I'd ask other people if we can come
> >>        to a
> >>>>        better, specific,
> >>>>        name.
> >>>>        E.g. Session Smuggling?
> >>>>        Better "Overloading" even if is less than
> >>        "Puzzling"?
> >>>>
> >>>>        I'm nitpicking about a name, I know, but at this
> >>        point I
> >>>>        think it's
> >>>>        important to choose the right one, considering the
> >>        effort in
> >>>>        finding a
> >>>>        standard naming convention.
> >>>>        Feel free to disagree, of course :)
> >>>>
> >>>>        Cheers,
> >>>>        Stefano
> >>>>
> >>>>        Il giorno lun, 26/09/2011 alle 15.12 +0100,
> >>        psiinon ha
> >>>>        scritto:
> >>>>
> >>>>> Hi folks,
> >>>>>
> >>>>> I've just added a new vulnerability page for
> >>        Session
> >>>>        Variable
> >>>>> Overloading:
> >>>>>
> >>>>
> >>        https://www.owasp.org/index.php/Session_Variable_Overloading
> >>>>>
> >>>>> This vulnerability occurs when an application
> >>        uses the
> >>>>        same session
> >>>>> variable for more than one purpose.
> >>>>> An attacker can potentially access pages in an
> >>        order
> >>>>        unanticipated by
> >>>>> the developers so that the session variable is
> >>        set one one
> >>>>        context and
> >>>>> then used in another.
> >>>>>
> >>>>> This is entirely based on Shay's whitepaper
> >>        entitled
> >>>>        "Session Puzzles"
> >>>>> linked from the references.
> >>>>> I've renamed the vulnerability (with Shay's
> >>        agreement) as
> >>>>        I think it
> >>>>> makes the issues easier to understand from a
> >>        developers
> >>>>        point of view.
> >>>>>
> >>>>> While this could be thought of as 'just' an
> >>        application
> >>>>        level
> >>>>> vulnerability I agree with Shay that this should
> >>        be
> >>>>        treated as a
> >>>>> distinct category in its own right.
> >>>>>
> >>>>> All comments welcome...
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Simon
> >>>>
> >>>>> _______________________________________________
> >>>>> OWASP-Leaders mailing list
> >>>>> OWASP-Leaders at lists.owasp.org
> >>>>>
> >>        https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OWASP-Leaders mailing list
> >>>> OWASP-Leaders at lists.owasp.org
> >>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >>>>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Stefano Di Paola
> > Chief Technology Officer, Lead Auditor ISO 27001
> > Minded Security - Application Security Consulting
> >
> > Cell: +39 3209495590
> > Email: stefano.dipaola [at] mindedsecurity.com
> >
> > Minded Security S.r.l.
> > Via Duca D'Aosta, n.20 50129 Firenze (FI)
> > www.mindedsecurity.com
> >
> >
> _________________________________________________________________________________________________
> >
> > Pay attention, this email is confidential. If you are not authorized,
> > or if you have received this message by mistake,please not read,
> > use or spread any piece of the information above.
> >
> >
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20111001/b1092ae5/attachment-0001.html 


More information about the OWASP-Leaders mailing list