We Keep Coding

How to implement basic security for my CRUD web app in ASP.net Core 2.2?

I have followed a wonderful tutorial by Microsoft on creating a MVC web app using Core 2.2 (https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-mvc-app/?view=aspnetcore-2.2). After completing this tutorial I was able to build a similar web app using a different product. For simplicity I will stick with the "Movie App" example from the tutorial to ask my question.
Below is the view of the basic CRUD application created.
I would like to provide some basic security for the web application. So far I have been unable to find a solution that meets my needs which are as follows:
Simplicity. There will be only one user who needs any privileges and that is me. The privileges will be full use of CRUD features (I am the only one who can click on any of the blue link in the above image).
No login requirements for the public. I would like anyone who visits to be able to be able to make a query from the search box (not shown in the picture) and see the results. I just don't want them to be able to make any changes.
Not to have to spend too much time on security so I can continue learning in areas better suited to newer developers.
The bulk of the options I am finding are enterprise level, complex beyond my skill level at the moment, or require everyone to be a user. If I am the only user is there a way for me to easily create one user account and maybe a second factor like an IP lock? If not is there a better approach for me to take in tackling this issue?

OK, one thing you have to implement is "some" kind of security / Login - so that the application knows "someone" has logged in. In your case, it needs to know that "you" have logged in. So you have to implement some kind of basic Authentication mechanism, so that the user "identity" is known. You can take a look at basic cookie authentication here. You don't need to implement any major claims system - a simple authentication is enough (for your non production / learning scenarios).
Once you have implemented some kind of authentication / login system, after a successful login (authentication), the system knows that the "user" is authenticated. Then in your Razor code you could simply check for this condition & then remove the links for Unauthorized folks & on controllers you could add the "Authorize" attribute so that back-end code also checks for authenticated users for relevant functionality.
eg: In Razor code, you could include conditional links to Edit / Delete etc, like so:
#if(User.Identity.IsAuthenticated)
{
//Include links for Edit / Delete
}
And you can include a mix of [Authorize] attribute on relevant controllers and [AllowAnonymous] on relevant methods.
Hope this helps. There is no escaping some basic understanding & work.

What's the deal with custom ASP.NET MembershipProviders?

I'm hoping someone can help me wrap my head around what's going on when I try to implement a custom MembershipProvider. This is probably more of a theory question than a code question...here's what I have:
MVC 2 app (started from an empty MVC 2 project)
SQL Server DB with my own "users" table
A User class, UserRepository, UserService, blah blah blah
Currently, my application authenticates via the UserRepository which returns a User object if successful. This User object is then stored in the session and is subsequently interrogated by all controller actions that require authentication.
Now...I understand that storing this in the session leaves me vulnerable to session hijacking and that a more secure method would be to implement my own MembershipProvider. What I don't understand is, where would this custom Provider end up storing my User object? I see that the overridden ValidateUser() method just returns a bool, but I can't figure out where that information is persisted for that user's time on the site.
I'd really like to keep my existing process while making it more secure by taking away the dependence on session for user authentication. I like having a complete user object at my disposal throughout the application once the user is logged in, but I'm open to suggestions otherwise. It seems that a lot of the MembershipProvider documentation is kinda black-box. I'm hoping that someone can explain what it's actually doing under the hood to persist user authentication.
Thanks in advance

Once a user is validated ASP.Net Membership creates a token (a large encrypted string) that is stored as a cookie or as part of the URL string depending on how you configure it in the config. It can optionally do either based on whether cookies are available or not. The token is used to persist the identity of the user to answer your main question about how it works at low levels. Everything else associated (roles, profile, etc) is retrieved from the server depending on how the custom provider is implemented.
It's not necessarily true that this is more secure than session - it has the same vulnerabilities of URL or cookie replay if the site is not protected by SSL encryption (worse with URL in case the users email around url's to others).

Take a look at the way Microsoft did there's they released the source
Provider Source
Also remember nothing is a black box in .Net you can use Just Decomile or reflector to learn more about how others(Microsoft) have done the same thing you want to do.

Aside from all the answers, I believe the missing link in your post is ASP.Net Forms Authentication - this is actually what uses ASP.Net Membership in an ASP.Net web application.
So if you have your own db and auth scheme (already) in place, you can use Forms Authentication with it - even without trying to make it work with Membership (you really don't have to).
Here's (quickly becoming my most used link) an overly simplistic MSDN example of Forms Authentication with the scheme hard coded. It shows you that you can even do it that way - not that you should of course, but just shows you the possibilities.
As all the answers above have stated, you can build your own provider if you require. The farthest I've gone (so far) hasn't been to build one, but just customize a few methods. Reason: the existing user db of a project I had was using MD5. This meant I just overrode 2 methods (if memory serves that is) - ValidateUser() and CreateUser()....
Hth

Here's an excellent tutorial on implementing your own custom MembershipProvider.
http://www.codeproject.com/Articles/165159/Custom-Membership-Providers
That being said, you really need to read the article. Once you read the article and follow the steps, you'll start to understand the answer to your questions. There's really not a great way to understand it other than going through the drudgery of following a tutorial like this. At least, that is my opinion. I just implemented my own custom membership provider for the first time by going through this tutorial. After a few hours, I was able to start implementing my own encryption algorithms.

I would highly recommend using the standard Membership Provider but creating a link table to join your existing user repository to the asp net membership provider. Best of both worlds.

Question: Authentication using SQL Membership Provider

I have checked the following article on how to use the sqlMembershipProvider. My question, is this the way most of the asp.net applications authentication schemes implemented.
Is there any other method, any references will be quite helpful for me.
Edit1:
My intention is to know the other possible ways, I can authenticate a user against a standard database.

"Most" is unfortunately hard to quantify.
MSFT has made it easy to setup an ASP.NET application using SqlMembershipProvider for an out-of-the-box setup, making it super easy to get authentication against a SQL db working.
That said, I rolled my own, because I didn't need much of what the built-in stuff was doing.
The way I did it was to write my own membership provider class, and use the web.config to specify that my customprovider was the default membership provider.
For ASP, there are other ways of doing authentication, such as using NTLM (basically creating windows users for each web user, and using Windows built in authentication).
Short answer: If you can make use of SqlMembershipProvider, and it does all that you need, then I recommend using it.

I reckon #Alan (+1) makes good points.
On a simple level if the (trusted) framework you are using offers you a solution that needs configuring rather than coding and it covers your needs unless there is a compelling case against it then it is probably a good solution.
You wouldn't write a new textbox control in asp.net, or a new fadeOut method for jQuery - you would use the provided solution.
I've rolled-my-own in this area and used all kinds of plug-ins and third-parties over the years. But in the project I'm currently working on we needed user authentication on Tuesday of last week and with SqlMembershipProvider the security module was complete by Wednesday. That's good enough for me!

Flexible ACL in ASP.NET

I'm building an application for which I want to use roles managment applicable to individual pages. That is, restrict users' access to pages based on their roles. These roles are stored into the database, as the users. This is the PHP way of doing things and I'm trying to port this to ASP.NET
What I need is that someone can point me to the right resources to look at to acomplish the above task. Until now I have not been able to find what I am looking for.
Thank you.

I think you should checkout the ASP.NET membership provider model:
http://msdn.microsoft.com/en-us/library/sx3h274z.aspx

If you are looking for fine grained control then take a look at Rhino Security

Can Bots/Spiders utilize Cookies?

I am trying to detect is a visitor is human or not. I just got an idea but not sure if this will work or not. But if I can store a cookie on the persons browser and retrieve it when they are browsing my site. If I successfully retrieve the cookie can this be a good technique to detect bots and spiders?

A well-designed bot or spider can certainly store -- and send you back -- whatever cookies you're sending. So, no, this technique won't help one bit.

Browsers are just code. Bots are just code. Code can do anything you program it too. That includes cookies.
Bots, spammers and the like work on the principle of low-hanging fruit. They're after as many sites or users as they can get with as little effort as possible. Thus they go after popular packages like phpBB and vBulletin because getting into those will get them into a lot of sites.
By the same token, they won't spend a lot of effort to get into your site if the effort is only for your site (unless your site happens to be Facebook or the like). So the best defense against malicious activity of this kind of simply to be different in such a way that an automatic script already written won't work on your site.
But an "I am human" cookie isn't the answer.

No, as Alex says this won't work; the typical process is to use a robots.txt to get them to behave. Further to that, you start to investigate the user-agent string (but this can be spoofed). Any more work than this and you're into CAPTCHA territory.
What are you actually trying to avoid?

You should take a look at the information in the actual http headers and how .Net exposes these things to you. The extra information you have about the person hitting your website is there. Take a look at what Firefox is doing by downloading Live Http Headers plugin and go to your own site. Basically, at a page level, the Request.Headers property exposes this information. I don't know if it's the same in asp.net mvc though. So, the important header for what you want is the User-Agent. This can be altered, obviously, but the major crawlers will let you know who they are by sending a unique UserAgent that identifies them. Same thing with the major browsers.

I wrote a bot that works with cookies and javascript. The easiest way of bot/spam prevention is use Nobot component in Ajax Control Toolkit.
http://www.asp.net/AJAX/AjaxControlToolkit/Samples/NoBot/NoBot.aspx