1

I'm trying to figure out what else I should (not) do to reduce the possibility of my web app getting hacked. And like most development efforts, while it would be great to have a security expert on the team, we don't have it.

My app is written in Blazor server side using Entity Framework. It uses the ASP.NET Core Identity library for authentication & authorization. And I'm about to enable 2FA in the identity library and require it for admin users.

It then uses the identity library claims to determine what pages a user can view. And on those pages, what data they can see and what actions they can take. The app has no API, it's just razor pages.

This app has virtually no confidential data. It manages volunteer opportunities for political campaigns. So most of the data is very public. And the remaining data is available to all admins, and there are a lot, so not terribly private. What is at risk is bad actors creating false events, updating or deleting good events, etc. And as a political website, it could well be attacked by Russia, China, Iran, etc.

So a couple of specific questions on this framework:

  1. Is there any security value is saving what user from what IP address made every change to the database (using SQL Server Temporal Tables)? My thought is that this is of marginal use.
  2. Is there value in watching failed logins, disabling a user after N failures in 24 hours and disabling a remote IP address after N failures across all users in 24 hours?
  3. How valuable is it to require a new 2FA login when the user's remote IP address changes?
  4. What else should I watch for/do?
  5. If I have been hacked, or think I have, what data will the people figuring it out hope I have saved?

I say this based on a previous response I got to a question here. Yes it would be good if we had the time & resources to implement amazing security. Unfortunately, we don't and wishing won't change that.

1 Answer 1

1
  1. My question is why have an exposed database at all (if you do, since that's what I can assume based on your question)? If you can, hide it behind a firewall or reverse proxy so that only the local website can access it. This way you'd only need to log the operations the site and any users make, but yes logging IP addresses, usernames, etc. that make changes is a good thing. I'd recommend looking into applicable logging frameworks and seeing which one works best for you. Of course, you might need a way to access that, so see if you can't find a way to log that, too. (This will likely depend on your system.)
  2. Yep, this is standard practice! It's called rate limiting, though usually it's a little shorter than 24 hours (in my experience, 10-30 minutes is sufficient). It's useful to prevent brute-forcing attacks through the login page.
  3. This is also fairly standard practice, though generally speaking 2FA should be required with every login, so the point here is a little moot.
  4. A few things off the top of my head: DDoS and spam. DDoS attacks you've probably heard about: some kid builds a botnet and sends off millions upon millions of requests that your server can't handle. This is a bit more of a redundancy problem than anything else, but making sure you have redundancy and load balancing in place can help mitigate this. Spam attacks are similar, and if you're able to implement IP blocking, that'll be another use case for it -- say someone comments on a bunch of events in a short timeframe, that might tip you off that something's amiss. Also, making sure that people can't view or edit pages they don't have access to just by changing some identifiers (that's called IDOR, or Insecure Direct Object Reference). There are a bunch of other things in the OWASP Top 10 that you can take a look at and see if they apply to your project.
  5. Logs, logs, and more logs! If you don't have automatic logs in place for an endpoint, it's really hard to know about what happened to it. Also, backups in the event of ransomware or some other catastrophic data loss are super critical to have, even for a relatively low-risk application.

Hope this helps!

2
  • Thank you yes, this helps. The site will be hosted on Azure and the DB will only be accessible to the app and to my IP address (for SSMS access). I'm using Blazor server and entry to every page I check that the user has the appropriate claims - so doesn't matter what they have for parameters in the url, it verifies on the server side. Commented Dec 10, 2023 at 14:36
  • What I'll add based on your feedback, shorter timeout for multiple logins, watch for excessive activity from an IP address. Thank you. Commented Dec 10, 2023 at 14:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .