Creative CSP Reporting

Content Security Policy (CSP) lets you control which content is allowed to load on a page. It has a reporting feature which is intended to help you identify misconfigurations or missing sources in your policy. When the browser detects a violation of your policy, a report will be sent to the reporting endpoint(s) that you have configured.

When developing a policy, reporting helps you identify all the sources on the pages you didn’t think about. When you enforce a policy, it enables you to fix any policy problems without having to rely on users reporting them or customers escalating errors.

I have, however, found CSP reporting to be very useful in reporting other events in the user’s environment. I have implemented CSPs with reporting just to catch these events. Here are my examples in somewhat chronological order.

Et reisesøk for travle mennesker som ikke liker overraskelser

Jeg tar toget til jobb. Da må man forholde seg til forsinkede tog, tog som ikke går, og ganske dårlig informasjon om hvilke tog som går og når de gjør det. Sistnevnte har jeg hatt lyst til å gjøre noe med.

Da Follobanen åpnet og det ble mulig å kjøre gjennom tunnelen fra Ski til Oslo følte jeg et enda større behov for et tilpasset og forbedret rutesøk, særlig for oss som bor ved de første stoppene for lokaltoget fra Ski. Selv om rutesøkene viser både direkteruter med lokaltoget og reiser via Ski var det likevel mye jeg ikke var fornøyd med i søkene:

Fiddler Script for Access Control Testing. As seen on NDC.

Testing for broken access control is often a laborious and boring process. Few tools are available and Burp Suite Authorize is the most common. I wanted to build something with a bit more flexibility to cover for additional use cases such as 

• multiple users: why not test multiple roles of multiple tenants at once?
• sending a request for a different user first: necessary to test access control on deletion
• flexibility: configuration and possible to rewrite the code for your use case

En innføring i helse-IT for utviklere

Etter å ha fulgt debatten om Helseplattformen og Akson blant utviklere har jeg sett at domenet helse-IT er et område mange av de med IT-bakgrunn som deltar i debatten ikke har mye innsikt i. Jeg har heller ikke bakgrunn i helse-IT men har vokst opp i en familie der alle er i helsevesenet og kjenner folk som har drevet med drift, support, test, utvikling og tilpasning av journalsystem. Jeg har hørt utallige historier og hjertesukk fra alle mulige kanter. Hvorvidt Helseplattformen og Akson som prosjekt og valgene som er gjort er bra ønsker jeg å forholde meg ganske agnostisk til, det får ettertiden bedømme. Jeg ønsker å belyse hvorfor helse-IT har en del utfordringer og kostnader som gjør disse litt annerledes enn mange andre IT-prosjekt.

Working from home for a long time with unknown end date

5 years ago I was living in Nairobi, Kenya for many months while adopting my son. And working remotely. Here are my survival tips for prolonged home office situations:

Create a good physical environment

• Bring a monitor with cables home from the office if you are allowed and don’t have a large monitor at home.
• Sit comfortably. Invest in a good chair for the sake of your own back. Put books under your table to get the right height.
• Move around and get some variation: Take a meeting on the couch.
• For the periods when others are taking care of little children, lock the door to your room.

Be social

• There will be less coffee machine chats and informal exchange of ideas. Talk to your colleagues without formal meetings and let meetings be on the topic.
• If you are home with your family, meet regularly in positive interactions. Eat together, take breaks with your family and have some fun.
• When there are limits on physical social interaction, be creative. Call people. Communicate with colleagues, friends and family.
• Balance your interaction with fearful people if it impacts you negatively. If possible be the one who brings peace, calm and hope.

Organize your life and work

• Maintain your daily schedule as if going to the office. In addition to being available to your colleagues it is good for you and others around you.
• Eat regular meals. Eat varied, not just to get all nutrients but also to not get bored of always eating the same. Don’t snack too much.
• Plan your activities. You may not be able to shop at night and follow your daily routine. Schedule necessary out-of-work activities as a break and work focused before and after.
• Networks may be overloaded and you may not be able to work on any task at any time. Always keep an offline list of non-urgent items that don’t require you to be online and things you can do if the company network is down (training, documentation). Remember to make backups when you get back online.
• You may not always be able to carry on with your main tasks e.g. due to a lack of decisions and communication. Make a list of things you didn’t prioritize when things were normal and pick from that list whenever you need.
• Keep track of worked hours. Use a single number for surplus/lack of hours and update often as you will quickly forget how much you worked when it was split in irregular intervals.
• Respect your weekends. Work on workdays, enjoy time off when it is not a working day.

That’s how I managed working far away when it was not safe to walk outside the gates after dark, very unstable internet connection, frequent electricity outages (at worst it lasted 19 hours), constant lag when working over RDP, stress from government banning adoption to foreigners and fear what the consequences would be, risk of some nasty diseases, not seeing family and friends for many months and it wasn’t always easy to talk to them either.

Don’t panic! Get organized and settle into the new normal while it is necessary. Limiting physical interactions limits contagious diseases. You may not be in a risk group, but you still risk passing it along. And should you need health care for any other reason be thankful to all who didn’t contribute to hospitals and health workers collapsing under the load.

Serious debugging

When i started this blog the intention was to write about application security. I chose the name "Fix in the wild" as a twist to "Exploit in the wild."
I later realized that I was actually trying to fix quite a few things in the wild. One example was trying to reduce the number of snails in our garden. But the real fight soon started fixing some wild creatures indoors.
Our house was infested with grey silverfish (Ctenolepisma Longicaudata). We saw them frequently in the basement, but they also journeyed through most of the house. More and more we saw them getting trapped in drawers and kettles in the kitchen. We had to do something about this before it made one or more family member crazy.
We started making some traps. Silverfish tend to get trapped in kettles and other objects of metal, glass and plastic with smooth and steep sides. We tried to make some traps where they could climp up, fall in and not get out. But the real problem was to find an effective lure. I must say that we were quite lucky, because one of the first things we tested turned out to work well. Suddenly we had a very effective trap, and best of all it was fully non-toxic!
This was totally different from what I was working on in my day job, but at one point these two worlds actually touched each other:

As we now were on the right path countless iterations of improvements to trap and lure followed. And to make a long story short we got increasingly better results, started a company and designed a trap for mass production. Then we had to figure out designs, webshop, suppliers, bottles for lure, accounting, and all the other bits and pieces necessary to launch the product.
Now we have already taken our first orders and welcome everyone to https://www.silverfish.no. Initially we only take orders from Norway in our webshop. Give us some time and we'll see if we can serve more countries. With time I'll perhaps even have time to write about security again...

Fighting mixed content with report-uri

On the Internet we see a great adoption of and push towards HTTPS. More and more sites are using HTTPS, getting certificates gets cheaper and easier and browsers are increasingly discouraging the use of HTTP. I want to take part and bring all our clients and users into to the good world of HTTPS.

For many sites it is quite straight forward to switch from HTTP to HTTPS: Install a certificate, fix some URLs and set up some redirects. Others, like Stack Overflow have found it to be much more involved. At my job we had a good mix of users on HTTP and HTTPS as our clients have had the freedom to choose. I want to remove the option for weak security entirely. The first problem is that "fix some URLs" is about fixing a million URLs and second that almost all of those URLs are controlled by our clients. The consequence of having these URLs referencing content on HTTP would be that browsers would choke on mixed content when everything is loaded over HTTPS. The page loads over HTTPS but requests content over HTTP. The result could be lacking security indicators in the browser or blocked scripts and style sheets which quickly leads to a really bad user experience.