Posts

In my years of working as an application security (appsec) penetration tester I’ve come to the conclusion that there are so much more value to be added than pure technical vulnerabilities. To deliver the most value you have to be willing and able to walk the extra mile. Before getting into what can be done to increase the value, let’s dig into the two most common types of vulnerabilities. Technical Vulnerabilities The technical vulnerabilities are the most common vulnerabilities we see. This is where the application is abused to do something it shouldn’t, for example by injecting code or abusing weak cryptography. Even though the vulnerability is technical, it is important for the reporter to describe how it will impact the business. Otherwise the receiving organisation might not have enough of an understanding to prioritise the issues, and handle them accordingly. Even though a code injection can be used to pivot to other machines, the main impact for the business can often be linked to the confidentiality, integrity and availability of the application. As a tester it can be hard to accept, but a dom based XSS might be an accepted risk if the only impact is defacing the sight by pasting code into the searchbox. ...

We live in a world where technology compete for our attention, especially on our smartphones. Apps do everything they can to get us to open the app, and not leave it. At least that’s how I feel, with endless newsfeeds, notifications and autoplay, it’s so easy to just open the phone and get stuck. The feeling is not new, but the thing that pinned it down for me was the book Zucked by Roger McNamee [1]. It highlighted the reason for the feelings, both why companies do it and what they do. By using data companies have on their users they maximise their consumption. This can be in the form of video content on a streaming platform or browsing the newsfeed on social media. ...

Technical debt has become a common term when discussing the quality and maintainability of code. There are a lot of definitions of the debt, but they all have some things in common, that debt are the things in the solution that should be fixed but haven’t been fixed yet. This could include everything from lack of documentation or test coverage to code complexity. The debt might not have been there from the beginning, but rather been introduce while the solution grows. Another common denominator is that the debt will increase the cost of continued development within the solution. This can be seen in several different ways, for example adding a feature to a complex codebase would require more time than adding the same feature to the simple. ...

So here we go, I finally got around to building a blog, and after looking around at different options i ended up using Jekyll and github pages. In addition to getting me this webpage, it allowed me to get some basic insight into ruby, making this a case of two birds one stone. Getting things to work have been quite a fiddle, so lets walk through how I got things up and running. ...

One of the most common tips you hear in regard to security is to not click links, but how malicious can a link be in this day and age? In this article I’ll discuss the risks I see and what impact they may have, to initiate a discussion about these risks. The thing about the internet today is that everything is links, and many sites such as twitter and bit.ly use link shortening to track usage and hide the original address. This makes it hard to know beforehand if the link is legit, and thus might increase the risk, but the impact will be the same. Here are four risks that I see when clicking a link. ...