Humans are the weakest link
API Security is a hot topic! The security aspects of APIs surfaced 1-2 years ago big time. Let this post be the touch into this delicate subject about which I have only little practical experience. I need to engage developers to this topic and make more practically oriented post a bit later. I’ll throw in here some thoughts on the subject.
Building secure APIs is also preventing API consumers to create security risks or leak private data. Take the security as a build-in feature, a part of the DX rather than something heavy and separate thing - an add-on. Great security is taken into account already in system design phase.
According to Nordic APIs the security threats “2020” are, some picked here:
- User Privacy
- Mass Overload Attacks
- Knowledge Gap
- Testing the Unexpected (discussed more later in this post)
- Building own systems, The devil is in the details when it comes to security
Common Anti-Patterns and OWASP top 10
The Open Web Application Security Project (OWASP) is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security. OWASP top 10 list, which identifies the 10 most seen application vulnerabilities as such:
- Broken Authentication
- Sensitive data exposure
- XML External Entities (XXE)
- Broken Access control
- Security misconfigurations
- Cross-Site Scripting (XSS)
- Insecure Deserialization
- Using Components with known vulnerabilities
- Insufficient logging and monitoring
API security related antipatterns are:
- Publicly exposed secrets (leaked to github and other systems as part of the configuration)
- Strong user authentication without strong authorization
- Not identifying the source of the API call
- Lack or loose security controls
- Incompatibility or lack of oversight when using multiple security tools
- Poor securing of communication channels
Everyone wants to automate all that is possible at the moment. That’s what we do at Platform of Trust as well. It brings speed and saves costs. Possibly even occasionally reduces bugs and mistakes. Doing automated security testing for APIs is probably not a subject for which you would not find some solutions. I have hard time believing that you can get really good coverage of security tests with just automation. Keep in mind that all it takes is just one big hack and your service or platform is most likely doomed or at least nearly that. You might survive a security flaw causing privacy leaks and alike but I would not count on that.
White hat hackers
If you have not heard about white hat hackers yet, you should digg into the subject now. A white hat hacker is a computer security specialist who breaks into protected systems and networks to test and asses their security. White hat hackers use their skills to improve security by exposing vulnerabilities before malicious hackers (known as black hat hackers) can detect and exploit them. Although the methods used are similar, if not identical, to those employed by malicious hackers, white hat hackers have permission to employ them against the organization that has hired them.
But you want to involve people (hackers are people too) in the testing. The hackers are ….drum roll…developers! Hackers are not some subhuman species but they are developers, often highly talented and focused (security) developers. You want their experience and skills as well as creativity. AI possibly can simulate human hacker to some extent at some day, but our ability to mix logic and random intuition is unique. That is hard to beat. And those skills are needed if you want to hack a system. The most obvious holes should be caught with automated tests.
Using hackers in enhancing the security is not peanuts business. White hat hackers in HackerOne service earned over $19 million in bounties 2018, a single hacker passed more than $1 million in earnings. Hackers can make a good income by putting the skills in good rather than bad/criminal activities. Some more hackerone stats:
Where are the hackers in HackerOne coming from? Not a surprise that Russia is one significant location. Indians probably see the bounties as lucrative way to earn money and they have huge population, so hackers might grow on trees. Or India based hackers are so plenty that they form a hacker swarm and thus raise in the report.
According to HackerOne money is not the only reason to participate:
- “I started doing bug bounties because I could do that on the side to really perfect my skills, and then I had a chance to legally hack against all these random third-party companies that encouraged it.”
- “The reason I hack is because I like the challenge. I think this is some kind of intellectual challenge for me because hacking is like finding something that others will not be able to find and thinking like how some others may not be able to think.”
- “When you find a bug, your heart starts racing. You keep going back, chasing that feeling over and over again.”
APIs are not the biggest part of the systems to hack. Websites are the most common target, but still 6,8% of the cases are API related.
Hire a hacker…or buy access to hackers
Mårten Mickos kickstarted HackerOne service to offer white hat hackers to test and asses system security. In other words hackers for contract. I’ve used the Finnish counterpart of HackerOne, Hackr.fi, once when I was Product Owner of national authentication system for K12 education in Finland. We launched a campaign with Hackr.fi service and gained information on possible attack vectors and flaws in permissions in filesystem, but no serious (?) security holes were found.
Run campaings as a subscription mode?
Of course hiring hackers to fiddle with your service (API or something else) takes time. If I recall corretly the period we had the campaign open was 6 months. So it’s obvious that you don’t do this kind of security testing after every bug fix or minor update. The length of the campaign (or slowness) makes it hard to use these services. You might have time for this kind of operation for example when getting ready to launch new version of the API. Optimum would be to have constantly open campaign going on, but that is not something I’ve seen yet. Keep the moneybag there, let the hackers find the holes and reward them. Keep the campaign on like a subscription plan.
Some more to read from 100 Days DX
- #85 - Great Developer eXperience requires fluent internal workflow
- #84 - Theory of Economics of Developer eXperience
- #83 - The Space of API Design Decisions is missing
- #82 - Purpose of API Evaluation Framework
- #81 - Should We Move to Stack Overflow?
- #80 - Four data driven ideas for improving API documentation
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!