Web App pentesting: Code review

Viewing 10 reply threads
  • Author
    • #5706


      I have been asked recently how I do a pentest on web applications. As you know, the methodology could be similar of a network pentest, but it ends up being quite different.

      So the question was: “Do you test application on your server, so you get source code that you can upload it at your web server in lab?”

      First, I have to point out that when I pentest a webapp, the network and the server (read OS) is always outside the scope. The web server (WebSphere, Tomcat, WebLogic, JBoss AS, etc) is usually in the scope. So I barely use nmap and other similar tools…

      I start by spending a lot of time talking to people and reading documentation. My goal is to understand the goal of the application. Why is it there? What is the subject matter? The target audiance? Other systems interacting with it (Web Services)?, Etc. I find out that the reconnaisance phase for doing a good test of a web app takes way more time than for a typical network. The reason for that is that I often make recommendations on how they can change a given process so it becomes more secure. But recommendations on process changes without understanding their business is rarely useful for them. Others may have a different view on this, but I spend about 3-4 days on reconnaisance for a web app pentest. On the other end, some tasks are much faster than for a network pentest or just not required at all (OS fingerprinting?).

      So far, I always had access to the source code so yes, I do code review. My background is developing web apps, so I can find my way in these applications. But usually, you don’t have to read every single single line of code. Instead, I look at each layers (Presentation, Sevice, Data or something similar) and from there, I can easily spot vulnerable code. I spend about 85% of my time doing a pentest and 15% code review.

      BTW, they never want us to download their source code and for various reasons. First, they don’t want us to download their database and a web app without database is like a Ferrari without tires… Also, they don’t want us to reuse their code, etc. So when I do a pentest of a web app, I almost always work on site, in a QA environment. At the end, I still review the prod server because their may be differences between the QA and the prod environment, but I spend about 90% of my time on QA. After all, it is the same source code!

      So other than the code review, I usually spend a lot of time analyzing traffic going to and coming from the application. I spend about 70% of my time doing this, along with fuzzing and trying to find vulnerabilities. Once I found one, I go in the code and find where the flaw is. In my report, I sometime give pieces of code that would fix the vulnerability (but I don’t do that all the time. It depends on the situation).

      Also, I always train a few developers so they understand how to validate inputs, how to “trust” other servers, etc.

      I spend about 2 to 3 weeks on an application. I could do an ok job in 2-3 days, but a complete job that includes code review and detailed recommendations (not just: “there is an hole there!”) takes a bit more time. But again, this is a rough estimate. It depends on the size/security level of an application.

      Finally, Some good security-aware development team ask me to help them plan security in their design phase. They are rare, but they produce very secure apps!

      So, in a nutshell, that’s about it!

    • #35865

      Awesome write up!!!!!

      I have to do something like this starting next month (in like 2 weeks). I have been going through the OWASP testing guide and Web Application hackers handbook to get a better idea of testing methodology.This is very helpful.

    • #35866

      Thanks knwminus!

      I wrote that quite a long time ago and at one point, I thought I had wasted my time because no one replied to it. You have made my day!!! ;D

    • #35867

      Hit, this is what I usually do when I have to test against a web application server. (This will be based on a “credentialed” test). One of the first things I do is similar to what you mentioned. Determining the function of what the web application does, how it interconnects within the network (if at all visible). To avoid a wikientry:

      1) Determine the objective – full compromise, escalation, vulnerability (e.g., do they just want some CSRF, tampering, XSS)
      2) Determining the product – what it does, why it does it, how does it do it for (clients, vendors, internal personnel, etc)
      3) Determine the application, its rev levels, its installation base (Redhat, Windows, Solaris, etc)
      4) Determine the technology behind it (Tomcat, SAP, Peoplesoft, Oracle)
      5) Determine what technology I NEED to apply (e.g., Paros, Peach, Klocwork, PaiMei, etc.)
      6) Have I done this test before, if so – what worked what didn’t… Have I done this in a lab before, if so – what worked what didn’t…

      Once I have these laid out, then and only then will I know which route to go, which tools to use, what works, what doesn’t, what might work, how in-depth will I be able to go based on time constraints, costs, etc.

      Typically, I have done testing against some of the big ERP’s and CRM’s (SAP, Peoplesoft) and I have also taken the time to make labs based on real companies using software from Oracle, SAP, Peoplesoft, IBM, you name it I “labbed” it up.

      Something I have a tendency to do is read alot about enterprise technology, what’s being used, by whom, where and how. For this I use the stock market as a metric (stock prices tell alot about whether or not I should waste time learning SAP over say SugarCRM…), I read CSO/CIO magazines and so on. Most of the big boys will allow test driving of their software via downloads or shmoozing. Anyhow, because many companies allow this test drive, I always try many of them out. Oracle, SAP, etc., I’ve downloaded tons of things, throw em on a VMWare image, create a realistic company (say 6 machines interconnected) then I attack it 3fold…

      1) How does the application move data (interconnection wise) – for this I’ll run something like Wireshark, Omnipeek, etc., to see whats going across the network

      2) What parameters are visible for tampering. Again, for something like THIS, I’ll use a combination of sniffers, fuzzers, Paros, etc.

      3) On my machine, what was “escalatable”, injectable, tamperable, etc., etc.

      I have a lot of notes I keep in folders for vendors, e.g., I have a SAP folder loaded with information because I discovered and reported vulnerabilities to them a while back. The tools I used at the time to discover them ranged from WinDBG, Peach, Klocwork Architect, Zed Attack Proxy, etc. I’ve found it becomes easier to create one’s own sort of DB for information. This way, when testing is to be done, one can pull up measured tools/exploits/methodologies as opposed to digging out ancient exploits on sites like exploit-db.

      As for obtaining “source code” for a client’s infrastructure, most clients when dealing with propietary systems would have a cow if you asked for code. It would also take far too long to overcome the legal-mumbo-jumbo “oh by the way, we’ve increased your NDA to $10,000,000.00!” (which is funny because the highest NDA I signed was $200,000,000.00 … 200 million … what damn pentest company has 200 million?!@) Anyway, I read what you wrote about enumeration, etc., I could go on a longer write-up but remember, I started by saying “This will be based on a “credentialed” test”

      For tests like these, I prefer to get right to the point:

      Client’s Goal: “Determine what can be broken”
      My objective: “Internally matters most… What can be done on the INTERNAL side of the fence outweighs the outside. Lock it down from the inside out, then re-test the outside in.”

      I’m not a big fan of WAT (WebAppTesting) only because they are very time consuming. The vast majority of “hacks” from the outside world are not from SQL injections, LFI, XSS, CSRF, Tampering… Those might be the attack vectors for say http://www.ThisIsMyPersonalCMSBasedOnJoomlaOrDotNetNuke.com” but in my reality, the vast majority of compromise comes via way of the client side… “What can someone do from the inside…”

    • #35868


      Great response. I am still but a noob but I am being thrown into some network testing and I don’t want to just run a tool and read the results to our developers without understanding what I am seeing and offering solutions. I feel like I maybe just a little in the deep end but that’s how I like to swim lol.

      At any rate, I hope the elearn security course, the LSO courses and my studies towards CEH and GCIA (I mostly deal in network security) will help me build my knowledge. I would love to do gwapt but it might be a little out of my league for now. Who knows though ;D

    • #35869

      @knwminus wrote:

      I am still but a noob but I am being thrown into some network testing and I don’t want to just run a tool and read the results to our developers without understanding what I am seeing and offering solutions.

      And this is why I always go back and state… “Understand the OSI… forget about the tools for now!”

      In my post, I gave you some of the steps I take, why I take them, what tools I may or may not use. There is a reason why I ramble on sometimes 😉 Maybe I need classes in making myself clear with posts.

      The reason why I detail my posts as much as I can is so that others can analyze/see where I’m coming from on the security scope. Most should already know how I feel about tools. Although I use them, I don’t advocate responding to posts with simple: “Use this tool.” responses.

      If/when I do mention a tool or a process, its because I’ve either tried to explain the reasoning behind it (which parts of the OSI am I engaging) or I’m trying to get people to think about things from an alternative scope.

      Since you DON’T want to read reports from a tool, that’s actually a good sign however, you failed to see where I was getting at: “Scope the entire process from the top down.”

      1) What is your goal
      2) How do you propose getting there
      3) What steps can you take to get there
      4) Do you understand those steps, if not go back and understand them
      5) What have you tried
      6) Has it worked, if not, what failed
      7) go back to step 1

      Most of the applications you will find are based on a common set of criteria that will ALWAYS BE TRUE

      1) They are networked
      2) They send/receive data

      Understand those two first and understand them EXTREMELY WELL. Once you do, things like parameter tampering, XSS, CSRF, etc., become *really* familiar. Want to know why? You’d be used to seeing them at the packetlevel by now. Once understood (networking) you can then move into the APS layers (Application Presentation Session) and things are more clear.

      Don’t be scared to dabble on your own time. Even 15 minutes per day studying something related to security helps. It’s all about your focus though. So re-read steps 1 through 7 😉

    • #35870


      My first response was “I understand the OSI model, I did Network+ , CCNA and CCNA:Security” but as I thought about it, I really don’t know the underworking frameworks like I should (particularly at the upper layers). I understand packets but only in a academic sense. I have never worked with packet reading in a professional level so while it is a new concept, the depth is new to me. So you are right, I have some studying to do. Guess I didn’t pick up that wireshark book for nothing.

      Do you feel it is easier to pentest once you are an excellent developer or so? Put a different ways, do I need to learn asp.net, java, etc before I pen test apps that use it?

    • #35871

      Guess I didn’t pick up that wireshark book for nothing.

      It’s funny, I was going to talk about Wireshark and how it helps visualizing the OSI model into the real world. Great minds think alike!  😉

      Do you feel it is easier to pentest once you are an excellent developer or so? Put a different ways, do I need to learn asp.net, java, etc before I pen test apps that use it?

      To me, it depends. You do not have to know ASP, Java or PHP in order to do an “ok” vulnerability assessment of a web application. Yes you need to know at least the basic of HTML, XML, SQL, Javascript and also AJAX and SOAP (web services) in order to understand what you are doing (or what tools are doing for you).

      Here is a quick list of task/main languages or protocole*

      1) SQL injection: SQL, database specific instructions
      2) XSS and CSRF: HTML, XHTML, Javascript
      3) Session management: HTTP Session, cookies, Javascript
      4) Server misconfiguration: Apache, Tomcat, IIS, etc
      5) Communication between servers (ex: web server to back end database): TCP/IP, SOAP, XML
      6) Data encryption: HTTPS, Hashing algo, etc
      7) Fuzzing: Every single language and protocols listed in this post!

      * Add TCP/IP, HTTP and HTTPS to every single line

      I probably forgot many tasks, but I just wanted to show that you don’t have to be a Java/PHP/ASP developer to perform these tasks.

      That being said, these tasks requires knowledge of the “main” language:

      1) Code review
      2) Security training for the developers
      3) Code injection (sometime)
      4) Pentest !

      Yes, I believe a complete pentest normally requires you to know the main language used be the web application. With the knowledge of this language also comes understanding of their framework, web server, etc. That being said, you really don’t have to be an expert at it, but trying to pen test a web app with knowing how to do simple tasks in the main language is to me, a mistake.

      But just take PHP for example. Install PHP, Apache and add MySQL to the mix. Create an “Hello World” program than create a “user” table in your database and create a simple logon screen. Then make your own logon screen secure (you will see, it is not that easy!). If your pen test requires AJAX or web services, create one or two of them and test them. After 2 or 3 days, you will know enough of the language and it’s framework to do a pen test. You don’t need 10 years experience, just a few days.

      It comes down to what sil says over and over again in almost each of his posts: tools can only do so much while really understanding what you are doing is key to a successful pen test. And as he says, you don’t need to have tons of experience with what you are testing, just a firm understanding of what you are doing!

      So you don’t need to know Java/ASP/PHP for a vulnerability assessment but you do for a pen test.

    • #35872

      Thanks for the awesome amount of lines written to the both of you 😉

      Glad to see the explanation of whether or not you need to be an experienced web developer for pentesting and how far you have to go in it, I’ve been wondering about that for a while myself. It’s pretty hard to be an expert developer AND an experienced all-around pentester at the same time. There is just too much to see.

      And how come that every time I read a post from Sil, I feel like standing in front of Everest with nothing but my motivation driving me upwards :p
      Nah just kidding, but thanks Sil for taking the time to explain so much.

      That’s it for praising EHN today, back to work now for me ^^

    • #35873

      Well now I know I have a project for this weekend. Thanks for the replies guys.

    • #35874

      Very good topic.

      Here’s a little bibliography:

      – OWASP Code Review Guide (free)
      – Code Complete (Microsoft Press)
      – Hunting Security Bugs (Microsoft Press)
      – Writing Secure Code (Microsoft Press)

Viewing 10 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?