I'm trying to answer your queries inline as below:
1) What is the procedure/approach you follow when doing a WebApp-pentest's.
-- I find OWASP testing approach best for web-app testing. Grab a copy of OWASP Testing Guide v3 and start working on it. It has test cases for all the stages starting for information gathering till Ajax/web services testing and covers all the areas of webapp testing.
2) There are some web-application's which start with a login page....so what is your or a best pentester's approach of going around the scenario.
(Is Bruteforcing the only method)
-- Before answering this question, I would like to share some knowledge on WebApp testing types. There are basicially 3 types: Black-Box, Grey-Box & White-Box. Black-box: No information about platform, technologies and source code given to pentester. The only knowledge he/she has is the URL to access the application. This exercise is used to conduct tests as external hacker which only knows about application URL.
Grey-Box: The pentester knows about the technologies, platform, user roles used in application and has access to demo accounts for each role. This test is conducted for user actions and to know how much can a legit user harm to the application. Things like Privilege Escalation, Broken Access & session management flaws will be discovered in this excersice.
White-Box: This is more like source-code audit. The pentested has comeplete knowledge about the application and has access to source code. This exercise will uncover logical flaws, secon-order injection, etc.
Web App security testing type to use depends upon the scope of the activity. If it's black-box and has first page as Login page, you will try things like Auth Bypass, User Enumeration, SQL injection, brute force, etc. If it's Grey-box, you will have demo credentials to access the application. Again OWASP testing guide is here to help as checklist to do things.
3) How do you do a pentest on a thick application's.(Is reverse engineering done in this case).
-- Thick application assessment is different as it's not use traditional browsers where we have many tools to intercept trafic from client to server. You need to look for tool or sometime code yourself the one depends on the application architecture. Then things like how data transmission is happening, is there any sensitive information stored at client-side can be checked. Reverse engineering is again depends on the scope of the activity and can be the part of application security assessment.
Hope this clarifies your doubts. Glad you like this thread. Reply in case you have more queries to ask.
Another question raises.....and it goes this way..:
I have been following this approach and this helped me a lot in making my webappsec concepts and technique's strong.
But my work has stoped at one point.
In these day's,most of the web application's are on ASP.NET and that too ,these applications are developed using the Visual Developer (drag and drop approach) where in all the kind's of security features are already implemented without the developers intervention to some extent(eg:when tryed doing XXS on my own developed app,gives and validate request warning etc..).
So,can you people suggest me how to go about doing a pentest on ASP.NET application's.
And also your experiences on doing a pentest on ASP.NET application's along with the vulnerabalities you had come across.
This would help me priorotising up my list for checking up the vulnerabalities against the application's.
Secondly wanted to add some more stuff which Amol had already added,that is:
I had developed my own vulnerable appliaction's in each language.I would suggest the people learning here not just to pick/identify the loop holes,but also to go a head and learn to exploit those loopholes(Post exploitaion techniques).
This would help you in learning the extra mile of tool's like BEEF,haveg etc. And also you will also learn the strategies of going for an attack(ex: if i get this SQL vulnerability........i can go/try for xp_cmdshell...etc)
ASP.Net applications are no different than any other web applications. There are many other frameworks which have introduced the security built in the functions since devs are bound to do mistakes. Thats actually a good move. Breaking such protections need a solid research. There are some researchers in past which had successfully broke some protections. One of them is: http://www.procheckup.com/vulnerabil...ateRequest.pdf
So if the devs are still using unpatched framework, you hav a pretty good chances to get xss.
In applications which has been developed with such frameworks, there are still chances to get issues with authorization as devs tends to develop their own logic without using built-in one. Also you will find web-services developed in such frameworks will be still vulnerable for various attacks.
Most importantly no framework can protect business logic flaws. A slight miscalculations can lead to very critical bug.
So if you encountered with a updated framework, you still should check for xss to catch a place where dev forgot to include protection. Also focus on areas which are not covered by framework.
That's my thoughts on it. Let me know if I missed anything.
Thank you very much for enlightening. From very long time more 6 months i was looking for something like this.
Your approach is very much practical. I have seen people suggesting "Web app hacker hand book" i think many suggest this book cos its easily available when you Google for web application security or hacking.
Learning PHP and using OWASP Testing Guide is best thing to do.
I have gone through the php videos and 104 pages of OWASP testing guide till now. I feel very confident now.
Again thank you very much. Looking forward for your "UI Redressing Attacks" at null meetup.
Can you guys help me with any pointer's on testing Java Application's(Web application's).The reason behind asking this question is, i have been trying to test java application's but i find it hard to intercept the requests (specifically the request through Applets) which make the POST and GET data into unreadable format.
Regarding the thick application pen test point, "Echo Mirage" can be used to intercept/alter the traffic and perform pen test. Also, depending upon development platform, you may include following testing vectors(most of them apply to internal testing approach considering thick clients would be accessible to internal employees) -
1. Verify accessibility to the executable / source code. As such, If the application is critical for the business process and the executable is just lying around anywhere or can be copied from the system, replaced with other executable etc, this can be considered as a flaw
2. Reversing the application to disclose source code / determine the level of obfuscation if any
3. Information disclosure via source code
4. Credentials / database information disclosure via source code
5. Try Crashing the application by providing false / large input values and observe the behavior (may get some good information by generating exception errors)
Yeah I am late but it is a nice post, and I am totally agreed that when we have no knowledge of making something, we can't get success in breaking it. So its cool to learn web development essentials first.
15Likes
LinkBack URL
About LinkBacks
Reply With Quote
Posting Permissions
Selective Symbolic Execution(S2E)
Yesterday, 08:33 AM in Reverse Engineering and Application Cracking