Printable View
My main interest in security is web application security, I'm interested in what if any Methodologies people use when testing sites. I currently use a modified version of the methodology suggested in "Hacking exposed Web applications".
So what Methodology do you use? :)
SittingDuck
This wouldn't be asking how do I hack would it? Surely not. You may want to consider clarifying the question, or alternatively getting some flame proof trousers.
No a methodology is a process by which a somthing can be done. In this case it's the process by which you would carry out a security test on a web application.
The methodology suggested by "Hacking Exposed web applications" is
· Profile the infrastructure
· Attack Web servers
· Survey the application
· Attack the authentication mechanism
· Attack the authorization schemes
· Perform a functional analysis (input validation attacks)
· Exploit the data connectivity
· Attack the management interfaces
· Attack the client
· Launch a denial-of-service attack
By using a methodology it helps make sure that things are not missed
However while I am testing a web application, I use my own version of this.
What I wont to know is what other people use, if they use a methodoloy at all.
I hope that clears things up
SittingDuck
Right answer - Welcome ;)
Normally I will start of with a "black-box" approach - normally trying to pervert query-strings, form values and hidden fields.
This means me trying to guess what processing is going on and subvert it. This does unfortunately yield results in some very badly made applications.
After that, I will try a "white-box" approach - actually looking at what the code does with specific inputs. Most problems come from incorrect validation or parsing of inputs, or double-parsing of stuff.
The favourites are:
Filenames with ../ in
Database int parameters which are not validated for being ints
Database string parameters incorrectly escaped for the database being used
Null characters in unexpected places
Allowing HTML to be injected into pages other users see by persisting it somehow (usually in files or DBs, then improperly escaping it when outputting)
(on Windows NT) Filenames which are DOS reserved names, use alternate file streams, are case insensitive or any of the other zillions of NT filename lamenesses you can get exposed to :)
Plus some other ones specific to given programming languages or web application environments.
How I normally prevent them - well obviously you *could* insist that everyone always escapes everything correctly but I don't think that's going to happen. Instead you have to move business logic out of the presentation layer and have an intermediate layer which handles correct persistance of data, and the problems start going away. Couple this with a strongly-typed language (which really IS a good security measure, honest!) and it just gets better and better.
Thanks your replay slarty
I find that 99% of the testing I do is black box ie. a penetration test. The only white box testing ie code review. I do is on my own sites.
Well here is the black-box process I actually use
1) Get a general view of the application. What is it's job?
2) I work out possible users classes for that application. This in most cases is three:
Unauthorized User
Authorized User
Admin users
This however will change with each application. Also in some cases you might not be given every account for testing.
3) I will do separate tests for each user class. I do this as they will nearly always have a different view of the web site.
4) This is the most important stage of testing. It is Surveying the application. This includes, trying to find every page, but at the same time I make a list of EVERY possible point of attack on every page. A point of attack is any where I can send data to the application, doing this makes the stage a bit easier. These are nearly always variables.
5) test all point of attack. This is where I use various methods SQL injection, URL manipulation, cross-site scripting etc. etc. Depending on what I believe the job of the variable I am testing is. This also includes trying to cause the pages to error. As this will often reveal lots of information.
(stages 4 and 5 are done for each user class)
6) Test the session management, As this is not dependent on the user class it is done after.
7) Write the report detailing all finding and suggestions on how to fix them.
As you can guess this way means a lot of work, but it does mean that things are less likely to be missed.
Slarty you are right in what say about all input validation should be done sever side. So for any one thinking of using JavaScript to do the input validation think again! But how to secure web application is another topic, but if any one wants to find out more try http://www.owasp.org :)
I didn't mean validation for correctness of data, I meant validation against potential attacks, for instance ints not being ints.Quote:
Slarty you are right in what say about all input validation should be done sever side. So for any one thinking of using JavaScript to do the input validation think again!
Sometimes the two go hand-in-hand, sometimes they don't.
Client side validation is great from a usability point of view but does absolutely nothing to protect your web app against malicious data (it is trivially bypassed).
In the case of validation against duff data, there is no need to provide nice error messages etc, because you're guarding against situations which should never happen (Murphy's law says it will)
Sorry by input validation, I am talking about both cases.
I agree with
but the difference at most very small, normally a question of not allowing a " or a ' or changing a ' to a ''. Other differences would include changing < to a < or > to a > you get the picture.Quote:
Sometimes the two go hand-in-hand, sometimes they don't.
I don’t know if you have noticed but developers often miss certain ones. For example drop-down in forms but they will get the rest. I think developers believe that it's not possible to change the values sent from these fields so they don't test them. Has anyone else spotted this?
So apart from slarty and me is there anyone else who uses any form of structure in their testing of web applications? :)