These slides were used by our security researcher Sven Morgenroth during the live demo of how to hack web applications and bypass firewalls. You can watch the live demo here: https://www.netsparker.com/blog/web-security/vulnerable-web-applications-developers-target/#livedemo

1. "Running vulnerable code
in local networks"
|| "how to get pwned by any website"
127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1

2. The web is broken!
Insecure standards, protocols and plugins
● WebRTC
● Leaks real IP behind VPN
● Can scan the local network
● SVG
● Not always blocked in picture uploads
● Leads to stored XSS, various filter bypasses, could be used to bypass CSP nonces
● Flash
● Unofficial competition between Flash and Firefox who gets most CVEs for code execution
● Exploit kit coder's choice

3. SOP is too permissive
● Cross Site History Manipulation (XSHM)
● Load images and scripts from any domain
● Frame all the web sites
● But X-Frame-options?!
■ Still leaks page loading times
■ In some cases window.open() also does the job
● Does NOT prevent making requests ONLY prevents receiving responses
● Cookies are sent by default

4. Are authenticated cross-origin requests necessary?
● Sending cookies when including remote images?
● Sending cookies when submitting forms to another website?
● Necessary? Sometimes.
● Should it be the default behaviour? Please no!
● Sending cookies with GET requests?
● There's not really a way around it
● Would annoy users

5. The Problem
● Users don't want to trade too much comfort for security
● It's up to developers to implement counter measures for those
shortcomings
■ CSRF Tokens
■ Same-Site Cookies
■ Checks for Origin header (web sockets)
● Developers don't want to trade too much comfort for security
● SOP is the enemy
■ crossdomain.xml
■ postMessage
■ CORS
■ JSONP

6. That's nothing new
● We know we should use strong passwords and 2FA
● We should implement every possible counter measure for permissive SOP
and other browser "features"
● We should not run insecure code in production
● We need to update our software

7. We all follow those guidelines
Except when we don't
well...

8. Let me explain
At what point do you consider your code as publicly accessible?
● While coding
● In your private repository
● In your testing environment
● In production ✔
✔
X

9. Wait what?
● My web server binds to 127.0.0.1!
● Other servers used for testing are behind a firewall!
● I am the only one who has access to my code!
● Windows Defender is up and running, so I don't even know why I watch this
presentation!11

10. You forget about your biggest attack surface
To hack your local application attackers can use
● CSRF
● DNS rebinding
● XSHM and similar attacks
● Timing side channels

11. Security guidelines
Now tell me again, at every stage of your web app development:
● Use strong passwords / 2FA / authentication?
● Exploitable through DNS rebinding, XSHM, CSRF
● Protect against CSRF?
● Exploitable through - well - CSRF
■ Also XSHM
■ Doesn't matter for DNS rebinding anyway if it's unauthenticated / passwords are
guessable
● Only run secure code?
● As hacker or security researcher?
■ Get another job.
● As a developer?
■ I have some small doubts here

12. Hacking the dev? Why not the server?
● Developers are the more valuable target when
● They have a copy of production data or access to backups
● They have access to other internal systems
● Production server is secured
● Their private movie collection is big enough (Critical mass > 500 GB)
● There might be multiple sites the developer is responsible for
● The application is announced but not online yet (startups, new features in
existing sites)
● There's a higher chance * to find buggy code in a development environment
● * Except if you develop the facebook messenger for android, chances should be equal then

13. But I'm not a developer
Good point. No testing environment, no vulnerable applications, right?
● Applications that run web apps on your computer
● Management interfaces
● websockets to exchange data between website and client
● Other devices in your network
● Your internet connected fidget spinner (or whatever monstrosity kickstarter creates next)
● NAS management interface
● One web interface almost every consumer has in the network
● Vulnerable home Router

14. DEMO
TIME

15. Well, this is bad
"That was a lucky guess with the default password. And stuff like an SQL injection
can't be abused just with CSRF while you are cross-domain."
● Completely right
● You can't read the response of a request
● You can't add data if it's a SELECT query
● OOB exfiltration is not possible without proper privileges
■ Conclusion: My data is safe!
XXX WRONG
● Oh come on, this is starting to get annoying
● Just because it is annoying. If you assume anything regarding SOP it's most likely wrong
● What's the matter now? How can an attacker possibly abuse an SQL injection
through the victim's browser even though there's SOP in place?

16. We've talked about them before: iframes!
Iframes can be used to extract data from an SQL injection
● Well, not only iframes, but also <img>, xhr and even the websocket API
● The problem? Leaking page loading times
● So what?
● SQL injection + delayed page loading time = ?
● Right. We can abuse blind SQL injections cross-domain!
● Seems like it's...

17. DEMO
TIME

18. Well, this is bad too
But what are the alternatives?
● Running your code in a VM
● Separation, but not that practical
● Can still lead to compromise of host machine or other machines in the network
● Code can be modified
● Don't visit the internet while you code
●
● Your code might require an active internet connection

19. Is there any way to be safe?
DNS Rebinding
● Side Effect:
● New host header
■ Shared hosting not vulnerable (only the default host)
■ We can whitelist the original host header
● Is it preventable?
● Yes. Either on application or server level (preferred).
● If the host header doesn't match a whitelisted value -> 403.
● Works for apache, IIS, nginx

20. Is there any way to be safe?
CSRF
● Problem:
● There might be no authentication yet
■ Critical functions might be exposed for everyone
■ No CSRF protection added yet
● You audit vulnerable code without CSRF protection at all
● There is not an easy solution for this
● Using frameworks
● Starting with
■ CSRF protection
■ Authentication
MEH

21. Is there any way to be safe?
(Experimental) Universal CSRF Protection in your environment? Conveniently
possible for PHP apps
● First: Create a file with the following content:

22. Is there any way to be safe?
Halfway done
● Next: Add the file to the PHP.ini directive auto_prepend_file
● This will automatically include the file whenever any PHP file is parsed. This works in a similar
fashion as PHP's require().
● This means, whenever a web page is opened it will
● Load the PHP file
● Check if a cookie with the name "access" is set
■ If it's not, it will just throw an error, set the cookie and stop execution
■ If it is, the file does nothing and doesn't interfere with your code
● Since it's a same site cookie requests can only be made from the same domain

23. Conclusion
Don't rely on SOP doing the right thing
● Everything we talked about is preventable, countermeasures are just not
always well known
● Developers and Security Researchers should keep in mind that their testing
environments are publicly accessible to a certain degree
● Even the average user is at risk. Passwords for routers should be strong and
unique like every other password
● SOP alone is not going to save you