Another good Gotocon video, although the first few minutes are a bit bumpy until the speaker gets into the main part of the talk.
The key points for me:
- Think about what security and risk mean for your system
- Add nasty strings from Fuzz DB to your existing tests
- Read OWASP
- Prepare for attacks and other problems
- Get to know your system’s normal behaviour, so you can spot when something suspicious is happening (rather than having to wait for something bad to have happened)
- Build a culture where it’s OK for a DBA to kill off a unusual and dodgy looking query – in his example it could have been a weird year-end financial report query, but actually it was an attacker.
- Can you match up all the logs end-to-end for a request and its reponse, and do you know what the logs means? By end-to-end that means firewalls, routers, applications etc.
- Log success and failure cases, e.g. logins. A run of 1,000,000 failed login attempts suddenly gets worse if it’s followed by 1 successful login.
Random Tech Thoughts 
I’m so glad someone else called out the “we push to production bazillion times a day” nonsense corporates are throwing out there. I Have automated many parts of my business, but I don’t think it’s right to have fully automated deploys.
Things I got from this talk
* Deal with low-hanging-fruit issues first. (Plain-text data, SQL Injection, XSS)
* You have to consider broader context of public metrics
* Unit test against known hostile payloads
* Log failed login attempts and successful login attempts
* Monitor your logs
* Foster a culture of learning not of blame
* Empower people to make decisions
I’m not sure I’ll use all of it (the way I unit test, we don’t query a DB, so SQL injection would have to move to other tests), but some things like parameterised queries, it was comforting to hear an expert say that’s pretty much how to stop SQLi.
LikeLiked by 1 person
Yes, that push rate vanity metric does make me wonder sometimes too – what does such a culture think of security testing, code review etc? I know you can automate, embed and / or move left many things so that they’re no longer a separate stage on the end, but I’m not convinced you can do that for everything of value.
Same here re unit tests and no db, but it’s got me thinking about how I could add it to system tests (which do use a db) via SpecFlow. (No answers yet, but it’s got me thinking the questions.)
LikeLiked by 1 person
Does specflow have wrappers to utilities like HTTP client’s and headless browsers? I’d imagine just testing the app works and produces required results, when paired with unit tests would be sufficient.
As you say, some things are very involved to formally automate, and the human process lives-on as a bit of a silent admittance. The requirement isn’t being fulfilled, but nobody can say that.
LikeLike
You can have whatever you can code in C# :-).
So you can use e.g. HttpWebRequest (https://msdn.microsoft.com/en-us/library/system.net.httpwebrequest(v=vs.110).aspx) for sending HTTP requests. I’ve used it quite a lot when testing our API, but you have to write quite a lot of stuff yourself to make it practical. For instance, I created a builder class that collected information for the request – bits of the URL, header info for authorisation or compression, body for POST requests etc, and put off creating and sending the HttpWebRequest for as long as possible. (This wasn’t how the first version of the tests was put together, and it got increasingly unpleasant until I restructured things to use a builder.)
For headless web browsing you could use Selenium. I’ve used it with Java rather than C#, but I think it’s not too hard in C# https://testingbot.com/support/getting-started/specflow.html.
LikeLiked by 1 person