0

I'm working on ASP.NET core MVC website, and I don't know if I'm missing any security risks that I need to watch out for (other than logical ones)

Here is a list of what I've studied and what I've done to protect aginist it:

  • Man in the middle attack (SSL, HSTS preloaded)

  • SQL Injection (never using data from URL, letting the framework filter them)

  • XSS (never using raw data, applying CSP)

  • open redirect attack (never redirect to anything that isn't local)

  • CSRF (always generating and validating the token at any post)

  • Click-jacking (adjust xframe options, deny iframe and apply same origin)

  • Brute force logins (limiting login attempts trails, locking account after certain amount of logins attempts)

Anything else I need to watch out for?

2
  • 1
    I'm voting to close this as too broad because you will essentially end up with another generic list of common web application security vulnerabilities. Webapp security is an entire research field and can't be discussed in a single SE question. :)
    – Arminius
    May 17, 2017 at 18:26
  • 1
    Have you looked at OWASP top 10 security risks : owasp.org/index.php/Category:OWASP_Top_Ten_Project
    – elsadek
    May 17, 2017 at 18:30

4 Answers 4

0

Proper session-handling and function level access control is a very important point in web security (Check out OWASP Session Management and Function Level Access Control).

Always make sure that session tokens are really only valid for actions that a certain user is allowed to perform. And only for that certain user.

That's a very big issue, and 99% of all websites I've tested so far were vulnerable to attacks evolving around that. E.g. when tokens could be used to perform actions, that the currently logged in user shouldn't be able to do. Like: replacing an ID in a request with the ID of another user (or record). You would be surprised how often that extremely simple method works to get PII of other users!

  • All urls are only accessible to users with the certain privilege.
  • Users shouldn't be able to simply add fields to a request. Good example: I saw multiple websites/apps already, where it was possible to hijack other user accounts by simply adding an 'email' field in the form where every user could change his own profile information.
  • Make sure that your way of granting roles to users/admins is safe, and that users cannot grant themselfes additional privileges/roles.
  • The password-reset forms are also often a good entry point for attackers, and be it only to spam other users.

Sessions must be destroyed on logout/password change, and not be reused at any time.


Apart from that you should also worry about information disclosure (when an attacker enforces errors, for example with invalid HTTP-requests or -methods, like OPTION instead of OPTIONS). And of course always make sure your website uses only the most up-to-date libraries (javascript, server-modules, and so on).

Never disclose any sensitive information - e.g. make sure that session tokens are never transmitted via GET-requests.

Also make sure that your server only allows certain HTTP-methods (e.g. don't allow "TRACE").

Input validation: secure all file-upload forms, they are very vulnerable. E.g. payload in the filename. I've also often seen that the maximum file-size was only validated on the client side.

Use captchas where needed, and make sure they can't be circumvented due to a bad implementation.

Last but not least you should also worry about open redirects.

There are actually many things you should be worried about. Injection for example: there's not only SQL injection, but Javascript-injection is also a high risk for the safety of your application. It happens more often than SQL-injection, by far.

I could go on with this list for a while, but I suggest you just follow up by reading some checklists like this one: https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/testing_checklist.html

3

Something I've learned from experience: developers (myself included) can and WILL forget things. SQLi is a great example: if you rely on developers to use an escape_string(user_input) every time it's used, they WILL forget.

Ditto XSS and XSRF: developers will always miss at least one place that strings can be escaped. And CSP isn't a 100% fix for XSS.

It's absolutely critical that frameworks/libraries are used that are invulnerable to those problems (or where opt-in is necessary). I don't know ASP.net specifically, so I can't really recommend one, but a term to look for is "contextual auto-escaping" (for XSS).

In terms of other problems, I suggest checking out the OWASP Top 10 - they do a pretty good job of showing what the important thing is.

One thing I'd watch out for especially is "insecure direct object reference" or "forced browsing" - ensuring that ACLs are applied at every page load. And going back to the first thing I said, they should be applied automatically - the developer shouldn't have to remember to do it. Any insecure behaviour should be explicitly opt-in.

Hope that helps!

2

The list you have is a good starting point, but there are many more you should be looking out for. Many of those are going to depend on what you are doing in your application, and what the requirements of your application are. Here's a short list to get you started:

Access Control:
Make sure that only users which are authenticated and authorized have access to your controller actions. Remember, any public method on a class that inherits from Controller may be requested from the web, not just methods which return an ActionResult. The best way to handle this is to decorate all of your controllers with the [Authorize] attribute, and any methods which need to be accessible by non-authenticated users should have the [AllowAnonymous] attribute applied.

File Upload related vulnerabilities: There are many possible vulnerabilities related to malicious uploads. If you are not properly sanitizing uploaded files, it's possible that a malicious user could overwrite some of your existing files, including javascript files and Razor templates (Look up local file inclusion for more information). You should ideally rename any uploaded files to something the user cannot control or guess. Also, this should ideally be outside of the web root.

Other areas to research are Server-side request forgery, Cryptographic bypass, Account registration/password reset flaws, etc. The list goes on and on.

0

As others have said, check out the OSWAP Top 10 Project. Note some new additions to their proposed 2017 list: Insufficient Attack Protection and Underprotected APIs.

Incapsula also has a good list of web application security threats that I recommend reviewing. Of course the recommendation is a WAF, but it's good that you are considering security at the beginning of design. You've covered some of these threats but also consider:

  • APTs
  • Social Engineering Attacks
  • Remote File Inclusions

and there are many more. Unfortunately, there's no end to threats but taking it seriously will reduce them substantially.

Can I ask, what functionality does your website require or what is it targeting as that affects specific vulnerabilities to pay extra attention to besides the (important) basics.

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