6

We have developed an ASP.NET Based Enterprise Application which is is soon to be released. Now, we are concerned about the security aspects of the application. I've been looking into Backtrack 5 and visited a lot of websites about pen testing too but it was not very helpful. I wish to test the developed application for security vulnerabilities using backtrack.

My question is how can I test my application using full capability of Backtrack?

Shurmajee
  • 7,285
  • 5
  • 27
  • 59
N.p Subedi
  • 161
  • 1
  • 4
  • 3
    N.p Subedi, welcome to IT Security SE! It is not advisable for developers to pen test their own apps for two reasons: a) you are not a professional and b) your hubris and mental fatigue will prevent you from exploiting glaring security holes. The bottom line: **hire a professional pentester**, and (in parallel) start exploring Kali/Backtrack and tutorials posted everywhere on the 'Netz. – Deer Hunter May 24 '13 at 12:00
  • Hire a professional... – Shurmajee May 24 '13 at 12:00
  • Kali Linux is the new "version" of backtrack. It's been re-named. – k to the z May 24 '13 at 16:12

1 Answers1

7

Linked are some videos which can give you a running head start: "Web Application Pen Testing Tutorials" however, firing off a tool or two at an application is not a reliable mechanism to ensure security. Since you stated: "we have developed an ASP.NET Based Enterprise Application", your best best is to work using say Agile or other SDLC based TEST CASES and create your own MISUSE cases. Link: "Software Security, Misuse, Fault Injection"

The reasoning/rational behind this comment is, you (the company, developers, etc.) are the ones who made the application. You know (have documented) how it is supposed to function, and what it is NOT supposed to do. You can create "specially targeted" attacks against your own application that can yield better results.

The issue with tools are, they are pre-programmed with "known knowns." Attacks and attackers all evolve. So relying on one tool can leave you still vulnerable if the author of the tool, was unaware of a new threat. This was the issue with JAVA recently where there were issues, Oracle would sandbox, an attacker would re-break it, they'd patch it, and another attacker would re-break that too.

For something like this (application testing), its a very broad thing. You can use fuzzers, networking tools, and a smorgasbord of everything and anything, and still get it wrong. It pays to begin from the ground up:

What does my tool do (test case)
How can someone abuse that my tool is supposed to do? (misuse/abuse case)

E.g.:

Test Case 1: Application takes input from user (a name)
Misuse Case 1: Rogue user tries to enter something other than a name (unicode, hex, etc.)

EDITED

I decided to re-comment on this since I see the "hire a professional" answer. While this would a better thing to do since "professionals" tend to be better equipped and experienced to deal with this, they too can and so fail. An SDLC like approach should be at the forefront of developing secure code. Testing against (hiring a pro) this SDLC practice should come secondary. There is a HUGE difference in penetration testing, and application security. See: "Writing Secure Code"

munkeyoto
  • 8,682
  • 16
  • 31
  • 1
    Agreed. There's nothing wrong with this gentleman learning pen testing. It will help when setting up secure systems. – k to the z May 24 '13 at 16:13