[Owasp-appsensor-project] Some hacking for the weekend (with an AppSensor and O2 Platform flavour)

John Melton jtmelton at gmail.com
Mon May 5 01:20:39 UTC 2014


Sounds awesome. Would be good to have a look at some of the amazing work
Colin's done on planning for adding appsensor to an application
(architecture). It sounds remarkably similar to what you have above.
Capturing the data is a significant first step. Hopefully the reference
implementation will be in a place where you can use it once you need the
analysis engine component. That way, you just issue a REST request from TM
to an "engine" and either poll for responses or get them via websockets if
you like.

Thanks,
John


On Sun, May 4, 2014 at 8:06 AM, Dinis Cruz <dinis.cruz at owasp.org> wrote:

> Thanks John
>
> At the moment here are the user activity logs that we track:
>
> *For users with account (or logged in)*
>
> Access Denied , Account Expired , Edit Article (Notepad) , Login Fail ,
> New User , Open TBot Page , Open TeamMentor , Password Change ,
> PasswordReset Requested , SessionId Not Accepted , Update Article , User
> Disabled , User Login , User Logout , User Password Change , User Search ,
> User Updated , View Article (direct) , View Article Html
>
>
> *For anonymous users *
>
> Open TeamMentor , 404, Application Error, Login Fail
>
>
> Note that we don't do any behaviour analysis or reaction inside TM's
> engine. We just push the data out in realtime, which is then visualised in
> a number of different ways (I need to write a couple blog posts on that, or
> if you want I can give you access to see it)
>
> One of the next steps that I would like to follow, is to map these
> activities into the multiple AppSensor detection points, and start
> thinking/implementing the logic that detects malicious activity.
>
> I would like to do this outside the main TM codebase, so that this can be
> a generic module that could be used on other apps.
>
> Btw, now that I'm starting to have data to look at, it is quite
> interesting how blind spots are easier to spot. For example, although we
> capture User Edits (and who did it), I just noticed that we don't capture
> 'user account status changes' for example when an Editor becomes and Admin
> (which could be an example of an CSRF attack). This is an example of an
> activity (or detection point) that requires code changes (and QA testing)
> since the logic to know if an user status changed, is quite deep into TM's
> code.
>
> Dinis
>
>
> On 4 May 2014 02:25, John Melton <jtmelton at gmail.com> wrote:
>
>> Dinis,
>> Very cool - thanks for sharing. This will help shape some of the ideas
>> going into V2. Very nice work.
>>
>> Thanks,
>> John
>>
>>
>> On Fri, May 2, 2014 at 6:08 PM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
>>
>>>  Hi AppSensor list
>>>
>>> I sent the email below to the OWASP leaders list. Since all of you are
>>> interested in AppSensor and security, here is a copy for the ones who
>>> didn't received it.
>>>
>>> ---------- ---------- ---------- ---------- ---------- ----------
>>> ----------
>>>
>>> As you can see on Please hack TeamMentor 3.4.1 (learn, maybe be paid or
>>> even get a job)<http://blog.diniscruz.com/2014/05/please-hack-teammentor-341-learn-maybe.html> I'm
>>> inviting the world to hack the app I'm been working for the past years.
>>>
>>> You can either do a pure black-box (on
>>> https://tm-appsensor.azurewebsites.net ) or look at the source code
>>> (clone from https://github.com/TeamMentor/Dev and run locally or in
>>> Azure (only needs .NET 4.0, no DB install required)
>>>
>>> There is quite a lot of OWASP influence in this release of TeamMentor,
>>> from the O2 Platform FluentSharp libraries (which make me a lot more
>>> productive as a developer), to the AppSensor-like features (see below) and
>>> the multiple OWASP-inspired coding strategies used to keep the app secure
>>> (look for example at the ASMX and WCF security tests or the .NET Security
>>> Demands).
>>>
>>> What is really cool and I'm very excited about, is the first pass at
>>> adding AppSensor capabilities to this app.
>>>
>>> Like I mentioned many times when talking about AppSensor, my main issue
>>> with the original model was that it pushed apps to add too much behaviour
>>> to the application in order be 'Appsensor-ready' (which could affect the
>>> application's performance/behaviour).  My preferred approach (which I've
>>> implemented now) is to first really improve the ability of an application
>>> to 'report and visualise' what is going on. This is done by pushing that
>>> info to 'somewhere' outside the app, then start thinking about how to
>>> detect malicious activity (from the point of view of that app) and finally
>>> what should be done about it.
>>>
>>> For the real-time data distribution (user activities, debug logs and
>>> request urls) I used Firebase mapped to an AngularJS UI, which really rocks
>>> (the firebase 'websockets content push' fells like magic). You can read
>>> most details about it in the 7 posts at
>>> http://blog.diniscruz.com/search/label/Firebase and if you want to see
>>> it action, create an account and let me know (i'll give you admin access to
>>> that Azure box if you promise to behave :)  )
>>>
>>> So have a go, and please share that blog post (and the server details)
>>> to others who you think might be interested (note that the last guy who
>>> reported a bunch of security issues with TM got a job out of it).
>>>
>>> The other area that I'm really interested in, is to have a couple
>>> threads on important security topics like: Data Encoding, Authentication,
>>> Authorisation, OWASP Top 10 issues, Application self-defence, Unit-Test
>>> driven development (with a security focus), Continuous
>>> Integration/Deployment (with security embedded in it) and
>>> static-code/dynamic analysis of multi-tear webservices+jquery based apps
>>> like this.
>>>
>>> Those are all things I worry daily, and as you can see, SI (Security
>>> Innovation) is pretty good sport at having this type of open discussion
>>> about their product (which has its code available in a public GitHub
>>> repository (it's not Open Source, but at least the code is all there)).
>>>
>>> A lot of the times we (the appsec guys/gals) are accused of talking in
>>> vacuum or providing security guidance on demo/simple apps. OK, here is a
>>> real-world app, with real-world complexity and compromises. Ideally OWASP
>>> should be able to help developers like me and protect these apps users.
>>>
>>> I know that sometimes it feels that OWASP is stuck and doesn't really
>>> connect with developers, but I have to say that as a developer I benefit
>>> tremendously from the knowledge shared by OWASP (for example the
>>> cheat-sheets), its projects (for example AppSensor or ESAPI (from which I
>>> took the 'concepts' not the code)) and chapters/conferences.
>>>
>>> Thanks
>>>
>>> Dinis
>>>
>>>
>>>
>>> _______________________________________________
>>> Owasp-appsensor-project mailing list
>>> Owasp-appsensor-project at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20140504/f83bb8a2/attachment.html>


More information about the Owasp-appsensor-project mailing list