XSS is still my name – a call for greater appreciation of developers

XSS is still my name

a call for greater appreciation of developers

Veit Hailperin
by Veit Hailperin
time to read: 10 minutes

The world is fascinated by hackers. Green font on a black background is as much a stereotypical signifier as the hoodie. It’s fascinating because it seems so incomprehensibly complicated and inaccessible. It’s fascinating because it has a hint of the forbidden. That’s as far as most people go. But some are so fascinated that they dig further into the issue and to their enormous surprise discover that it really doesn’t seem that difficult after all. A few months later comes the first mockery of developers and on Twitter they’re saying how simple offensive security is. But nothing is simple – not when you want to take things seriously and do it well. Offensive security is no exception.

Every specialist area has its hot topics. In IT security, it’s web application security. Web application security is concerned with the security of applications that can be controlled through a browser. As the term hot topic indicates, this was not always the case. Binary exploitation had its time in the sun. For a long time, network security was big news. But then the range of applications expanded and new methods of attack, such as SQL injection, were discovered. Web application security has been the hot topic ever since.

But in the security sector, there seems to be a trend at the moment towards strengthening network security again. This is presumably due to the large number of companies that have been hacked in recent months.

Easy start with XSS

The truth is, getting started with web application security is easy. There are plenty of good sources and programs that can help you begin. The Open Web Application Security Project (OWASP) in particular is an enormous resource. Beginners reading through the Top 10, will soon come across cross-site scripting (XSS) on the Internet. The faulty code, the cause of this gap, is rarely more complicated than the following example:

$username = $_GET[‘username’];
echo ‘<!DOCTYPE html><head><title>XSS</title></head><body>Hello ’;
echo $username;
echo ‘</body></html>’

The problem is clear: unsanitized output of an entered parameter. Attackers can exploit this by entering their own JavaScript code via the parameter username:


The alert box lights up. But how does it look if a template engine is involved and it has additional filters integrated in the compiler? This is exactly what happens with the popular JavaScript framework AngularJS.


AngularJS 1.5.7 has more than 31,000 lines of code. The framework offers its own template engine, which runs inside a sandbox. The sandbox is meant to stop any JavaScript code from running. Should an attacker manage to break out of the sandbox and if AngularJS is used incorrectly, and the sandbox is used by the developers as a security mechanism, this in turn leads to XSS. Although this may seem like many conditions from an external perspective, we regularly come across this situation in our tests.

The first sandbox escapes were relatively simple. However, several protective, preventative mechanisms were integrated into the template parser. Consequently, the current bypass for the framework looks like this:


Just to comprehend this kind of AngularJS sandbox bypass requires basic JavaScript knowledge, an understanding of how the AngularJS templating engine works and an ability to debug. Developing this kind of attack, which is actually the work of a penetration tester, requires more than just basic programming knowledge.

In the case of an AngularJS bypass, there is a video that explains the bypass. This video also offers a good insight into the basic skills and knowledge required to find vulnerabilities and develop exploits. A really detailed description of how the bypasses works was written by Jann Horn, one of the bypass authors, as part of his bachelor thesis.

The necessity of programming

A good hacker not only masters their own tools, they are also able to expand on them and develop their own. Anyone working in the industry who can not program would be well advised to learn as soon as possible. Script languages like Python, Ruby, Bash, Lua and PowerShell offer a good entry point. A good starter project is the automation of recurring documentation tasks, the kind of thing penetration testers would prefer to ignore. A good hacker does not do jobs that a computer can do better and faster.

What day-to-day tools will you need? Nmap, Metasploit, BurpSuite, Zap, Sqlmap. All of these tools have interfaces for expansion. If there’s a tool you use all the time, it makes sense to be able to extend it for your own purposes.

One phenomenon that I observe repeatedly is penetration testers that do not want to share their developments because the code is of insufficient quality. But releasing tools allows others to use them, find errors and sometimes set about tidying up the code themselves. Not only have you helped someone, you have also learned more about programming. The reason that getting a start in this field is so easy these days is that people have taken it on themselves to put their beginner code online.

Respect for developers increases rapidly once they start learning to program. The number of possible errors is so high that it’s little wonder the internet is full of holes. And that’s not including design errors.

Another positive aspect of programming knowledge is that instead of just criticizing, you can actively support developers. Developers may come up with excuses or propose poor solutions – it’s rare, fortunately, but occasionally it happens. And when it does, you can be there to protect the client. Of course being able to program also makes any kind of code review much simpler.

Debugging and developer tools

Last but not least, developer tools are great for testing. Of course, there are some tools that have been developed specifically for hacking. During web application penetration tests, proxies are essential. The trend toward one-pagers, meaning websites that exist entirely in DOM, is increasing. In order to audit DOM, a knowledge of the developer console is a must! It can also be practical to know how to develop your own browser apps and plug-ins. In any case, the most powerful means of testing client-side functions at the moment is the developer console. For testers who spend little time with – or even fear – the developer console, I recommend the following two articles as a starting point:

I’m not the first person to write about these issues. One article I personally find highly inspirational is by Andreas LindhHacking Open Source software for fun and non-profit, which looks at the whole issue from an operating perspective.

For beginners in the offensive security field, I can recommend the articles How to become a pentester articles by the Belgian researcher corelan and So, you want to work in security? by security engineer Parisa Tabriz. Both articles also look at programming.


Every budding penetration tester should consider it a goal to learn programming. Programming allows testers to think more like developers, using their tools for attacks, not to overstate ones findings and to improve security with patches.

About the Author

Veit Hailperin

Veit Hailperin has been working in information security since 2010. His research focuses on network and application layer security and the protection of privacy. He presents his findings at conferences.


You want to test the security of your firewall?

Our experts will get in contact with you!

Ways of attacking Generative AI

Ways of attacking Generative AI

Andrea Hauser

iOS Mobile Application Testing

iOS Mobile Application Testing

Ian Boschung

Reporting and Documenting

Reporting and Documenting

Michael Schneider

Transition to OpenSearch

Transition to OpenSearch

Rocco Gagliardi

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here