5 ways to get young people into web security – 10 minute mail

Disposable mail’s 17-year old security researcher shares his best advice

The IT security field is growing rapidly. More and more stuff is being connected to the internet, and existing services are expanding at a brisk pace. Consequently, there is a growing demand for IT security experts. We need to attract more young people who will grow up to be our future IT security specialists. Participating in Google’s bug bounty program at age 14 sparked my interest in web security. I have now, at 17, been employed by IT security startup Disposable mail for two years and written IT security-related columns for leading media houses in IT and tech. I am not saying that people doing IT security today have some kind of moral responsibility to attract new people, but I believe it would benefit everyone to expand the IT security community and it is therefore something that we should work towards.

Here are 5 ways that I believe we can get more young people into web security.

1) Welcome new people

Be open-minded towards new people. Help out when possible and answer questions that you receive. By this I refer to everything between general technical questions to more concrete help getting a foot into the industry. This is something I remember people were really good at when I started out a few years ago but things can always improve. When all my experience consisted of reading blogs and I was gasping for more someone I had got to know over the internet reached out with a ticket to SEC-T as their company sponsored the event and had a few tickets left over.

As with all new areas of potential learning I do believe that being able to ask questions without the fear of being judged is very important for development.

Many are also quick learners, and networking amongst new people may give results faster than you might expect at first. Being the one who helped out in the beginning also builds trust, who would not want to help out their mentor if they develop to such a position where it would be possible? Helping out new people pays for itself in the long run, so see it as an investment rather than charity.

2) Free resources

While attending a conference might be hard to pull off for the average teenager, an internet connection is all you really need. There are a lot of free resources available for free today, and in any medium you can think of. Defcon publish almost all their content on Youtube, and there are a lot of free text write-ups to mention a few. However, the existing information is not always that easy to find for someone “outside” the community. If we are going to improve on this area, we need to make the existing information more accessible. If you are releasing security content yourself, consider spreading it in channels outside the traditional security community. While it might be fun to be retweeted by some security guru that maybe should not be the only goal regarding content spreading.

The Internet is full of public sites to get information from, and you can just google for them as best you can. I would recommend to avoid following specific blogs at first but rather find sites that update with links to interesting posts. Anything worth reading in the beginning often finds its way to Hackernews or /r/netsec fast enough anyway. Building a personal network of interesting people on Twitter is also a great idea, but it takes a bit of time before it gets useful.

3) Challenge the stereotype

Even though people within IT can joke at the stereotype of a hacker, and feed it themselves, understanding it does not involve everyone and risks to scare away new people. A good example of this would be when the FBI director jokingly said that everyone in IT-security smoked pot. Did he really believe that would be a good way to get parents to encourage their children to go into that industry?

There are a lot of jokes about alcohol, drugs, etc. and I am not saying that we should stop joking about it altogether, but it is something to keep in mind. Would you introduce your teenager to a group of people that talks about alcohol as a necessity, illegal substances as something normal and builds bombs as a hobby? Most likely not.

4) Doable cool stuff

When I first started to write C++ at age 12 I stopped after a few days due to lack of patience. I realised it would take ages to be able to create the game I had as inspiration. ‘Hello world’ on the other hand would not have been a problem for my patience, but also not much of an inspiration.

People differ, but this is something I have seen with others as well. One of the better ways to introduce someone to programming and thereby security is to show off something that looks cool, but is still achievable within reasonable a time frame. One could call it a combination of the game and ‘hello world’.

Transferred to web security, maybe show off a simple reflective XSS at first? Let people play around with that, and when the lack of patience has been replaced with interest, start to introduce more advanced stuff and explain how and why it works.

5) The approach in school

Many say that programming in school should be mandatory. While that sounds like a good idea, we must be careful to not create a climate where it is forced upon students. Programming is an interest that must grow naturally. Even if you feel like it is the best thing you have experienced, not everyone will feel the same, and that is okay. I sometimes get the feeling that the debate climate is somewhat infected today because programmers hold a black and white view of it.

How fast you grasp the logic behind programming also varies a lot, so letting each individual study at their own pace is important. I have seen it myself in school where the ones that understood it quickly felt unmotivated and the ones that did not grasp it gave up and hated it altogether. Just focusing on the middle group is never a good idea, but it gets especially bad in programming where there is even more initial differentiation in knowledge.

I believe the process for the best result would be to make sure everyone is exposed to it, see what sticks, and encourage any curiosity around it that may emerge. Explain why and what is possible to do with that knowledge (similar to ‘doable cool stuff’) without making a cliché of it.


About the author: 

Linus Särud stumbled across the world of web security by accident after finding a virus on his computer. His career in web security quickly took off and at 14, he hacked Google. Now, at 17, he is a web security columnist at IDG Sweden as well as a skilled security researcher and much appreciated member of the Disposable mail team.
Twitter: @_zulln 



Find out more about Linus in our Meet the Team-series!

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

The Danger of Third Party Scripts – 10 minute mail

Our security researcher Linus Särud explains why you need to realize that a vulnerability in an imported resource is as bad as a vulnerability in your own code.

The web community can be seen as awesome. With just a single line of code it is possible to include external scripts to add functionality to a site without having to write anything ourselves. Or, if we want to, we can include someone else’s code as a base and then write our own on top of that (with libraries, for example).

Disposable mail Blog | Web console This is very common, and something that most sites do, this very blog being no exception. Fire up the web console right now and you will see a lot of external domains under Sources.

(We try to be as transparent as possible with the services we use, and you can get a list at https://detectify.com/services. Please observe that includes all the external services we use, not just included resources.)

I (Linus) remember my first personal blog, and the ridiculous widgets I used without thinking about the security implications. It was everything from a kitten following the mouse pointer, making the whole blog snow to more useful stuff like a guest book (you could not have a blog without a guest book, unwritten rule).

Professional sites today might not use kittens that follow the mouse pointer that often, but the rest still stands. In our own example, we use it for the comment section here and it was the easiest way to implement all the share-buttons below this blog post.

With all these advantages it is easy to overlook the issues caused by including third party scripts, which is what this blog post focuses on. There are two main concerns to take into consideration and although there is no optimal solution to solve this, being aware of the risks can help us make more informed decisions.


Vulnerabilities in third party scripts exist regardless of whether the script is hosted externally or not. This becomes a problem because hackers do not need to target you specifically – if they find a vulnerability in the code included, they can attack everyone that imports it, including you.

This also means that if someone were to target you specifically, they can search for vulnerabilities in the included resource that someone else has already found.

A great example of this problem is the XSS Mathias Karlsson found in AddThis. As the very same script is included on multiple domains this one vulnerability leads to an XSS on a million different sites.

It is not realistic to expect everyone to do a security assessment on each script imported, but there are a few bullet points to keep in mind to make better decisions:

  • Realize that a vulnerability in an imported resource is as bad as a vulnerability in your own code. An attacker could take full control over what is presented towards the user, executing their own scripts, etc.
  • Only use imported scripts from trusted third parties who you are certain take security seriously.
  • Keep it updated.
  • Consider importing it directly from the external provider instead of hosting it yourself. That way it can hopefully be auto-updated if any vulnerability gets publicly published. However, this would also introduce another issue, explained in the next part of this article.

The resource could change (does not apply to self-hosted scripts)

As the resource is loaded from the external source the external party is always able to change the content of the resource, and by doing so tamper with what gets executed on the site that includes the resource.

An external resource could change if the provider hosting the script gets hacked, or if they decide to go malicious and change it themselves. This introduces a single-point-of-failure situation, where an attacker could instead of hacking only you take the time and hack the hosting provider of the script and by doing so take control of all sites that include it.

It is possible to lock an external script to its current state, protecting against hacked external provider. If the script changes the inclusion will fail. This however prevents auto-updates, and can therefore be questioned if it worth including or not. See the last few paragraphs of this article for more on that https://blog.detectify.com/2016/10/27/cdns-minimize-damages-if-the-cdn-is-hacked/

For more information about subresource integrity, read Mozilla’s blog post.

Our research: How common are external resources amongst the world’s 500 most popular domains

We decided to look into how common these external resources are, and thereby also these single-point-of-failure situations. The result is the reason behind this blog post as we found it very interesting.

Our script loaded the 500 most popular domains worldwide and saved all the external resources loaded. It then extracted the domains it was loaded from, removed doublets per site and sorted it all after how common each resource was.

Technically speaking what we did here is loop through the list with domains, load each domain in a web browser using Selenium and after the page has successfully loaded extracted the src-param of each script-tag.

The results

It turns out that 40% of the most visited domains all have one domain in common:


Over 200 of the scanned 500 sites, include resources located there. However, as Google can be seen as trusted and not that likely to get hacked maybe we are okay with that? Looking further at the table we can see that they are also the one who clearly dominates the area with other domains as well.

However, skipping a few steps down exposes a few domains without the same reputation of security.

I am not saying that any of those fail to take security seriously, but are we really prepared to trust so big a part of the web to each and every of the players listed above? It is a question without a clear answer, but it is something that should be discussed more. Both from a security perspective, but also from a privacy point. Each of those companies are able to monitor everything you do at all the sites that include scripts from them.

As we believe there are many possible takes on this, and to drive the discussion forward, we have published the full statistic here. It contains about 1k domains that scripts are included from. The domains are those that can be found here: http://alexa.com/topsites/global

This is just scratching the surface of what would be possible to get numbers on, and feel free to take this research further. If you believe you have found anything interesting or want to discuss something related to this topic, feel free to reach out over hello[at]detectify.com!

Security tools

In addition to this, when running a scan with Disposable mail we highlight all external resources to help you get a better grip on the extent you use them as that sometimes can be hard to keep track of. I would guess that many times the included resources are long gone forgotten, and just going through such a list can be healthy.


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.