Application Level Security Testing
Results 1 to 6 of 6

Thread: Application Level Security Testing

  1. #1
    Junior Member
    Join Date
    Jan 2005
    Posts
    9

    Application Level Security Testing

    Hi,

    I hope I am not repeating earlier questions... I have tried to search through the forums, but nothing seemed to be appropriate. It's a tricky concept to word, however, so I may be duplicating the idea referred to by a different phrase.

    My challenge is thus: I work for a software testing department for a software company. We produce software that goes to end users, middle-tier operators and our own internal teams.

    While our IT department handles our network-level security (rather efficiently) at all tiers, our produced applications get a fairly cursory test from a security perspective.

    Most sites/books/tutorials/etc deal expressly with network-level security testing (with possibly the exception of web forms)... it would appear that application-level testing is a new and growing specialisation within the field. I am aware that there are tools specifically designed to test applications fro security flaws, but I have also been assured that they are not worth teh disk space they occupy.

    Would anyone have any further comments, or sources that I might peruse for more information on this shard of security testing?

  2. #2
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,883
    Here are some general guidelines taken from my own internal testing process. I have sanitized them just a bit but this should get you going (hopefully).

    1) Define application components - Example: Web front end IIS6.0, PHP enabled middleware, Oracle9is backend server farm.

    2) Define the scope of use. Who will use this app? Is this an internet accessible application? What kind of data is accessible?

    3) Map the mechanics of the application. User inputs, server data returned, etc..

    4) Using the above information, develop and attack vector list (tainted input attacks, literal parsing of commands, etc.)

    5) Have several team members (if available) design attack vectors independently. Meet and consolidate all ideas. This can include enumeration of step 1 without actually finding out. In other words, you may want to see if someone can map out your setup. This would be a bad thing given the right circumstances.

    6) Carry out testing.

    7) Produce a management report with a technical add on. All bases are covered this way.

    8) Determine if fixes are required or additional external testing is required.

    9) Repeat the process if necessary.

    --TH13
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  3. #3
    Senior Member
    Join Date
    Jan 2005
    Posts
    128
    edit: well there goes my post :P
    http://sfx-images.mozilla.org/affili...88x31/take.gif
    If You\'ve Done Something Right. People Wont Know You\'ve Done Anything At All - God (futurama)

  4. #4
    Junior Member
    Join Date
    Jan 2005
    Posts
    9
    Thank you very much, that is exceedingly helpful

  5. #5
    Banned
    Join Date
    May 2003
    Posts
    1,004
    Unfortunately the type of testing thehorse13 suggested will lead to poor results. Even more unfortunate is the fact that the type of testing thehorse suggested is likely to be the best availible to you.

    For an organization just switching to formal devlopment model I would suggest Boehm's V&V waterfall model. This will break your product down into smaller steps (feasability, plans & requirements, broad design, detailed design, actual code, integration, implementation, and upkeep) with each step have a validation (does the right thing) and verification (does the thing right) phase. Incorporated into this of course will be a test suite at each step, so at the code level, all you need to worry about is code level bugs, not design flaws and test accordingly... etc etc.

    Remember, a security flaw is nothing more that a system operating in a leveragable manner outside the design scope, if the design has not been verified and validated... an infeasable amount of testing is required to uncover all the potential problems.

    Ideally the test suite will be included into the products specifications and will include test data and techniques that will exercise all of the product's paths with testing outputs correctly predicted.

    This will save your company heaps of money, project time, and result in a better product.

    It might be beneficial to your career to do some more research on this and get a meeting with someone higher up.

    cheers,

    catch

  6. #6
    Junior Member
    Join Date
    Jan 2005
    Posts
    9
    We already have quite a complex formal testing structure within the company... unfortunately not as far up the development path as we would like, but we're wading against the twin tides of the legacy system and internal politics. I'm pretty sure a similar battle is waged around testing teams the world over

    Our internal structure is similar to the waterfall system, with a few refinements made to suit our end product environment... the testing that I am personally involved in occurs at around the integration stage. I'm just looking for techniques (and tools) that specifically approach testing from the perspective of security (I'm sorry for the confusion... in my head it sounded clear in my original post, but having re-read it I realise otherwise).

    thehorse13's suggestion of a component-based approach sounds like it could be quite effective. I'm busy badgering our poor abused developers for as much information as possible to map the communication pathways between the components and the mechanical responses... hopefully I can find a few cracks to drive a wedge into

    User inputs and the like are already pretty well covered by our general testing. Perhaps I can add a little SQL injection and the like to our web forms, but I suspect that the devs already test for such 'common' tricks.

    I like the idea of the black box enumeration. I'm curious as to how much information we can find from outside... might have a few nasty surprises waiting there.

    Anyway, thanks again for the comments. Some inspirational stuff

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •