13

I am trying to Pentest an application which is built in AngularJS. The difficulties that I am facing:

  1. Burp Suite's "spider this host" option is not able to crawl all the urls as most of the requests are AJAX and Angular based.
  2. When I am trying manually to parse all the links using Burp Suite. It is able to parse only home page link. Rest clicks are not intercepted.
  3. I am not able to get the contents of the templates used for various layouts. Like: "App/src/dashboard/Menu/Menu.box.tpl.html" is one of the template used in Angular Directive. But how to parse its html contents. (Just like we get html source for general parsed urls).

Here, Acunetix was bit helpful to give the brief idea how the application is parsing the contents. But for manual pentest I am not getting proper solution like which tools, methods etc I should use.

Please guide me if anyone knows about Angular App pentesting methodologies.

Is there any link/resource/tutorials out there for AngularJS app pentest?

Improve this question
1
  • Just generalities (so a comment and not an anwser...) but client side applications can be vulnerable to man in the middle: try to spy the exchanges with wireshark (if not encrypted) or with browser internal debugger to see whether it is possible to workaround any security through IHM with direct forged requests.
    – Serge Ballesta
    Commented Aug 8, 2016 at 10:22

2 Answers 2

Reset to default
5

Thanks atdre for the opening.

On this note, pentesting JavaScript applications has become very complex. Newer web architectures have essentially become containers. Now some would argue on the term(s) I use, but the idea remains straightforward - web apps now run in objects.

The impact on the way we scan and pentest apps is then greatly impacted. Simply, the usual web proxy approach just doesn't cut it anymore. From Burp to Zap, Charles, AppScan and many others - these tools are more and more limited when it comes to rich JavaScript apps including Angular, Node.js and many other libraries and architectures (front and back-end).

Especially true in the last year, we now have to use the web consoles in browsers and more modern tools and approaches as apps are running in the back-end and in the front-end only or mostly. We don't get that back and forth from the server and the client anymore - at least, less and less.

As JavaScript essentially runs in the client/user browser, I've seen augmentation in this reality during my lasts pentests (12-24 months). The more I try to intercept and play around with comms between both... the less I see and can do.

On this note, most of my processes needed to be "upgraded" and updated.

As such, I now most usually run recorded sessions with tools. One of this example is using the Burp recorder. In the last year it was greatly updated to enable the recording of web sessions and not only login sequences. Simply import.

This approach has the capacity for the tool to record a real user session (think selenium script) and then replay this session with the included data and "real-time" user and data flow.

Remember, as more complex JavaScript runs in the browser, the only way you will see the flow and related data and logic is within the web session itself! And from one session to another you may gain more perspective in the process. It's nuts, long and yes, very frustrating sometimes.

Yeah, at some point you'll see a comm leave for a back-end server or API but most of the logic and processing has been done in the browser (input, validation, construction, rules, variables, etc.).

This now means that we can't rely on a "simple" proxy or plugin for interceptions, manipulation or similar. Again, maybe you'll see the occasional comms going out, but not like we used to see.

So my biggest recommendation at this moment is this. Record, replay and reuse (wash, rinse and repeat) and stick to that browser web console (check versions, variables, functions and rules). And trust me, it will take time to understand the app flow, certainly longer than a simple interception.

We now have to dig deep in the JavaScript code and hope teams and tools will get updated with modern scanners as this is becoming a serious mission manually. What used to take a few hours may take a week now.

As most app I test - I don't know them. So I think the quick blackbox tests are a thing of the past. We now have to go much deeper in code and flow to get results.

Some links to help...

https://forum.portswigger.net/thread/burp-seems-not-able-to-crawl-html-in-angular-js-application-9b9a9a2b

https://forum.portswigger.net/thread/singe-page-application-built-using-angular-js-6-e9a88e65

https://blog.nvisium.com/angular-for-pentesters-part-2

Improve this answer
4

Used to teach app pentest classes for a Fortune 20 appsec vendor to Fortune 100 clients. Years ago the state-of-the art for these types of assessments was the OWASP Ajax Crawling Tool where one had to manually input all of the Ajax parameters and actions.

For AngularJS, there is the AngularJS Batarang Chrome Extension in the Chrome Extension Store -- very useful for debugging. If you also happen to run into Node.js (likely), then you can also leverage the iron-node debugging tool. If you do any Javascript prototyping or development, I also suggest checking out the ternjs (Intellisense-like) add-on to the Atom Editor. nVisium Security wrote up a blog post on some of the security issues in AngularJS. Dinis Cruz also writes on AngularJS regularly.

Single-Page Applications can be worked much more efficiently using BurpKit, and to get an efficient crawl, check out htcap.

Improve this answer
6
  • I tried batarang also. It helped in understanding the layout and template structure. But I was not able to edit/modify to test the scenarios as we do in developer's tool. Moreover, blog links and Burpkit, htcap info are awesome. Many thanks @atdre
    – Jassi
    Commented Mar 13, 2016 at 12:31
  • 1
    I found good video about burpkit: youtube.com/watch?v=csMN9sEiDUI it's very fantastic video. I hope it will be useful.
    – za_al
    Commented Aug 8, 2016 at 9:13
  • 1
    Just wanted to provide some input on the nVisium Security article you posted. That's really a horrible example of "bad security" on the AngularJS side of things, as it boiled down to "restricted data is stored on the client-side and accessed via a permission flag that is ALSO set on the client-side". It wasn't a security limitation of AngularJS in particular, but a security limitation of any client-facing code.
    – Patrick Bell
    Commented Aug 8, 2016 at 14:45
  • gitlab.com/wirepair/browserker
    – atdre
    Commented Jun 4, 2020 at 15:58
  • 1
    Too bad I can't fully answer this question as I have a clear process for this... In the past months, Burp Suite Pro and Enterprise has changed, and it's now very easy to record a full session (including generated JavaScript and more). Once you've crawled what you want in the integrated burp browser or using the extension, you simply create an automated scan using a "login sequence" that's in fact the full session you just recorded. You simply paste the JSON data back into the automated scan login window in Burp and you are good to go.
    – deijmaster
    Commented Mar 2, 2021 at 10:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .