by smarri on 3/30/24, 12:29 PM with 58 comments
by gerardnico on 3/30/24, 3:55 PM
Just escape every input: For sql, to avoid sql injection: https://datacadamia.com/data/type/relation/sql/parameter For html, if somebody try to inject html: https://datacadamia.com/web/html/entity
You got 99% of security holes patched.
All the best
by solardev on 3/30/24, 2:11 PM
Implement some basic rate limiting by IP so you don't get your Google Maps API DoSed. Block China and Russia altogether unless you expect customers from there (sadly, many bots & drive-by scans originate there). Sanitize your inputs, especially if you have any that will reach one of your own endpoints like for a database lookup (and look into SQL injection prevention in general). Use prepared statements in PHP if you use that for DB access. Not sure about Python.
You can read OWASP guidelines for other best practices (https://owasp.org/www-project-top-ten/) or ask ChatGPT to summarize. But realistically, Cloudflare takes care of so much that it seems a bit foolhardy to try to DIY it these days...
If it were me doing this, I wouldn't self-host anything at all, and just use managed services all the way down, including the DBs. A lot less maintenance that way, especially for solo devs. Lets you focus on the business logic instead of trying to reinvent your own secure little nano cloud. It takes serious manpower to stay on top of the latest vulnerabilities and zero-days, and IMO it's not worth spending your limited time on that when the big clouds can do it much more cheaply and much more thoroughly... it's a full-time job in and of itself, and you still probably wouldn't keep up with all the latest attacks =/
Of course you end up learning less this way because other professionals do all the hard work for you. But unless you want to become a backend/security professional yourself and REALLY dive deep into this stuff, I don't think just having basic security skills is going to do you much good anyway, since it takes all of 30 seconds to spin up a pre-hardened cloud host these days, usually for free, and they will have much more exhaustive coverage. Just my 2c.
by mycentstoo on 3/30/24, 3:28 PM
- Serve traffic behind a load balancer that has a WAF
- Network segregation for database (separate subnets)
- Make sure you serve https and have a cert that’s valid. Redirect to https if http
- Restrict ports on LB
At some point later:
- Endpoint monitoring and threat detection
- VPC flow logging
- Execute backend as non root
- Dependency / artifact scanning
- Cloud SIEM to monitor common actions taken
- Make sure no hard coded creds. Ie, use role-base auth with cloud providers
- Reproducible infrastructure builds with infra as code
- Email domain protection
- Grab misspellings of domain names to prevent squatting
by kqr on 3/30/24, 4:21 PM
by mrkeen on 3/30/24, 1:03 PM
* Disable SSH access for 'root' username.
* If you're using JWTs anywhere, don't mistake them for encryption - they are not.
* Check you're only serving over https.
* Don't trust your frontend. Any security check built into the frontend is near-useless, as the user can reprogram it however they like.
* Strings is how you let the baddies in, especially if you manipulate and concatenate them. Read about SQL injection to find out more.
by Semionilo on 3/30/24, 5:03 PM
Never trust your frontend data ever!
Always assume the attacker can talk to your API.
Don't do auth or login yourself. Use known libs, workflows asks.
Have unit tests to verify your endpoints need auth (valid user not just a anonymous user)
by apwheele on 3/30/24, 8:30 PM
Now, this does not allow me to say do python web-apps (that are not WASM). Hostinger has VPS for quite cheap I would consider if I needed that (if AWS lambda does not make sense, I did a python google cloud app engine for a month, https://crimede-coder.com/graphs/Dallas_Dashboard, and that was pricey, like $80 a month, whereas the WASM app is no additional cost). And I am sure there are other vendors that are similar (I am just happy with Hostinger).
So in terms of DDOS protection this is not so great, but that would not be a big deal to me. So site goes down, but I do not rack up a bill or anything.
For a google maps application, I not un-commonly see people put API keys in javascript client side (not good!) I mean it depends on what exactly you are doing, but if it is a public service that users do not sign into, just rate limiting the number of API queries in some PHP + database logic server side should be not too much work and reasonable to not rack up a surprise bill (I forget if google allows you to limit the API keys directly or if they will just rack up bills).
by precommunicator on 3/30/24, 4:22 PM
by forgotmyinfo on 3/30/24, 7:16 PM
by chrisjshull on 3/30/24, 8:12 PM
by rgbimbochamp on 3/30/24, 6:14 PM
by g_p on 3/30/24, 3:52 PM
To turn the question around a bit - you've identified the possible routes of compromise/exploitation (i.e. untrusted user input). The first step to me is a threat model. Work out the "so what" of why someone would try to attack you. What would be their end-goal?
To give you a few first steps, you've mentioned using a Google Maps API, and searching based on device location. Presumably your use of the Maps API is paid, and therefore a potential motivation for an attacker is financial, coming from your use of that API. Therefore treat that (i.e. the ability to make requests using your Google Maps API key) as a "target" in your architecture.
From there, you can do things to be a less attractive target (rate limiting, limiting results shown, if you are charged per-result). You could also review your code logic to ensure that only the right kind of request can be made (i.e. that someone modifying the client-side can't trick your server into accidentally making entirely arbitrary paid maps API requests on their behalf).
At this point, you'd also want to figure out your threat model between client-side and server-side, and what is exposed where. Assuming your server-side makes the API requests to Google Maps (and if not, then you're presumably exposing your API creds to clients, which is a "stop right here, don't proceed" moment!), what is allowed to flow from client to server? Can a rogue client get your server to make an arbitrary query? Would that let them use you as a free Google Maps API broker?
Understanding the trust architecture between front and back-end is (for me at least) key, as that's the primary exposed attack surface to an end user. Open up developer tools (F12), and look around requests as you use the app. Is there anything here that you wouldn't want users to see? As attackers will definitely see that, and it will be the first place they go to look at what you are doing!
Other ways to mitigate these risks could be (if you have sufficiently constrained input sets) to implement caching to avoid the ability to rack up queries against the underlying maps API. Given you are using arbitrary user locations, that's a bit harder. If users have a session or other short to medium term identifier, you could do some smart rate limiting to detect rampant scanning of large areas by making API requests that spoof the device location to be loads of different locations.
If you follow this process, and work out what's worth attacking (your infrastructure will be one of them - even just to compromise the site, post spam, etc, as will things like any database you run), then you can begin to understand those risks, and work out where there are attack vectors, and mitigate them methodically. The OWASP top 10 guidelines are a good starting point - often the biggest issues are design mistakes, omissions of basic omissions, or flawed attempts to implement basic measures. If you have authenticated API endpoints, for example, is the authentication logic correct, and meaningful? Does it actually do what you intend, and is what you intend sufficient for the level of security you want to have?
by traviswingo on 3/30/24, 3:43 PM
As you launch more and spend more time dealing with users the default things to do will become second nature, and you’ll find yourself using the built in tools from AWS, DigitalOcean, CloudFlare, etc. rather than rolling them yourself.
But seriously, just launch. There’s a really good chance you won’t have any problems.
by smarri on 3/31/24, 4:38 PM
by phonon on 3/31/24, 6:19 AM
by joshxyz on 3/30/24, 12:41 PM