Ask HN: How are you securing your apps in 2019? | Hacker News Reader

Ask HN: How are you securing your apps in 2019?

Hello makers,

I’m curious to understand how much of a priority security is for the apps that you create and develop.

Arguably, security is paramount and a key consideration for every step in the development lifecycle to ensure that the user’s data is protected.

On the other hand, there is a clear need for speed in getting features shipped. It’s easy for security to move down the priority list.

How do you secure your code and applications? What tools do you use, if any? What tools have you used in the past, but didn’t find useful? How should security testing tools look like in 2019?

View on HN

I got a lot of good tips from https://observatory.mozilla.org/

It gives a clear rating, and readable, concrete advice to get you to the next level.

I also block the SSH port on the firewall level, unless I need to do some maintenance (and then I only unblock my IP address). So the SSL port is the only open port most of the time.

Good one, I didn't know that one yet. For the dynamic scans, I can also suggest https://www.securityheaders.com and https://ssllabs.com/

you'll find both of these in the 'third party' tab of observatory. But indeed, I also got a lot of good from these, especially ssllabs

I brought down over 50 websites July 31st, 2018 (and didn't activate 20 others). In the hope I could get more secure hardware. And to tighten up software/websites I'd already developed.

Hardware

I'm moving to late model hardware. My workstation is a 09/2018 computer. When Intel/AMD get Spectre/Meltdown solved in hardware, I'll probably buy an even newer computer. I'll try to buy as many non-Chinese components as I can. You can get a computer assembled in the U.S. But you still get parts made in China. As soon as possible I'll buy or accept a router from Verizon that uses WPA3. I'll turn off UPnP (Universal Plug and Play) if I can. Monitor the line (passive/active taps) Put the router behind a cage/door with a security lock. Move to a more secure office environment.

Software CSS (Content Security Policy - my code was probably written before or as the levels were being thrashed out) check what's going into and coming out of Local Storage ...

Tools Kali Linux Metasploit Wireshark AIDE SELinux Security Now with Steve Gibson & Leo Laporte ... Microsoft's Enterprise Security subscription, whitelist the computer programs that can run on Windows using their signatures

Particularly with Docker a lot of security can now happen at the OS level. This is great because it requires no changes to code, particularly for super legacy apps where there simply is no way to secure say PHP 5.4.

HTTP Security Headers. These are big. There are 8 or 9 of them now. Content Security Policy especially.

GeoIP Blocking. Also this is big. I think AWS WAF lets you even filter down to the state level now if you want. This dramatically reduces the open ip space you’re exposed to. Easy to circumvent yes, but still large benefits.

4096 SSL keys. Also would disable anything below TLS 1.1 (TLS 1.2 would be better).

SPF, DKIM, and DMARC records for DNS address.

IP Blacklists. Lots of known malicious IP lists you can download daily and block with IPTables. If you’re using Docker, you can block via Apache mod_rewrite and a fast look up dbm file (convert from txt to dbm via httptxttodbm tool).

ModSecurity. A pain to setup sometimes, but it’s not bad. Just enable a few options and you’re ready to go.

These are excellent suggestions Bucephalus. One note though, they mainly deal with the infrastructure/network/os level security.

A simple SQL injection in the code would still be exploitable regardless of the countermeasures above.

So on top of what you have suggested, what are your ideas to get the security right on the code level of the applications?

Well said, there are tons of issues the one can encounter even with perfectly secured infrastructure.

Somebody made good effort identifying some: https://www.hacksplaining.com/

Learn to think like somebody who will try to exploit your system and embed guards into your code as you build it.

> 4096 SSL keys.

Why do you say this? You should keep in mind the following:

1. Most TLS vulnerabilities occur due to design or implementation flaws, not due to insufficient key size (in particular side channel attacks of various flavors);

2. RSA is not the only algorithm which can be used for TLS. In fact, it’s not even the most advisable one. You can also use authenticated encryption via AES-GCM or Curve25519. These are safer. “4096 bit keys” are not a coherent recommendation for these algorithms, because security doesn’t correlate with key size;

3. You generally want to choose libraries which are secure by default and don’t require (or encourage!) developers to make decisions about details like key sizes. Choose an algorithm if you kust (avoid RSA!), but limit further decision making.

What about mobile apps ? what specific measurements are you taking, besides common methods and techniques. How are we save guarding apis consumptions. And most importantly reverse engineering techniques.

I think for API consumption one important consideration is keeping API keys secure. Besides that, most of the modern issues I have seen are related to authentication and access control.

Regarding reverse engineering, I personally feel that this is not as important an issue as others. Anyone that get's access to an app or a mobile device will always be able to reverse engineer it. It is just a question of time and effort. Mobile apps mostly should have the same objective as modern browsers, as providing the UI and UX.

Business logic and security should be handled on the backend side.

If you are still keen on reverse engineering and resiliency against it, check out this document https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf.

GuardRails.io anyone?

We use Serverless lambda + api gateway + cognito, there is no room for getting hacked.

Famous last words ;)

While leveraginvg serverless gives a lot of benefits in terms of hardening and infrastructure setup, all the traditional application security issues (e.g. OWASP TOP 10) like SQL injection can still apply.

Reply on news.ycombinator.com