I am working on a web application which provide some services for its users who has accounts to log on to the web application. as you already probably know, it is possible to programmatically log in to web sites by providing username and password and sometime a catcha code. As I know it is possible to simulate the request programmatically. for example in c# we can make a request and fill all request headers such as User-Agent, Referer, .. and send it to the server in order to log in.
However, my question is how can I prevent users from logging in into web application via something other than browsers?
Thanks.
You can't. Timing, CAPTCHA and honeypot fields and using Javascript are common ways to prevent most robots, but someone dedicated to specifically targeting your site will find a way to simulate a genuine user.
All you can do it raise the barrier as high as you are able, and as high as is acceptable for your users. Security is always a trade-off against convenience.
There are ways you can raise the barrier, but each method's application varies across applications. For example, you could sniff the user agent and check it against a list and reject anything that isn't defined as a browser on your list. That kind of thing works for me in an internal situation where we have specific policies and controls over the browsers employees can use. For a web application however it would likely fail as the list would need to be managed, and people in the outside world probably know how to spoof their user agent anyway.
So it all depends. You need to consider the vectors around where your threats are coming from and guard against those threats as best you can rather than trying a blanket approach.
Related
I have a c#-based program that can send messages and files to our SlackWorkspace via my SlackApp (I'm using HttpClient to communicate with Slack).
Now, to distribute this program in my workspace and to make it so that every user will have his own identity, it says that I have to use OAuth and create verification-tokens, specific for each user.
It says in the Slack-documentation I have to use a redirect-URL (as per docs) to my own server.
We have a server that I potentially could use for this. But I have never done anything like this before and I am unclear on what "answer" I have to provide from our server. I thought the verification-process would be handled by Slack.
Anyone has an idea on how to approach this?
And before anyone asks - yes we need to install it for everyone and make them identifiable as themselves. We can't use the "SlackApp" as user. :)
I would be very grateful for code examples(in c#) and explanations on how this whole redirect-thing is working.
Slack uses the standard Oauth 2.0 protocol to authenticate apps, similar to Google and Facebook.
So the "verification-process" is indeed mostly handled by Slack (as outlined here), but your Slack app needs to initiate it and handle the responses properly. Also its a multi-step process and includes the user having to login into Slack with their credentials. This why you need a web app to handle the whole process.
To enable a Slack app to generate tokens via Oauth a web app is needed:
can be reached from the Internet
able to handle HTTP requests like a web server
has persistent storage for the newly generated tokens
This is probably easier to implement with ASP.NET Web Pages, which can utilize many functions from an existing web server.
But for this answer, lets look on an implementation in .NET Core. For that we need to create our own web server and some rudimentary session handling. Main concepts include:
HttpListener class for providing fundamental ability to listen and respond to HTTP requests
Handle multiple requests in parallel
Cookies / Session handling
MD5 hashes
The details go a bit beyond the scope of one answer. But I am happy to share a working example implementation on this GitHubGist.
Btw: For the local development of such a web app its recommend to use a VPN tunnel like ngrok, that allows one to expose a local machine securely to the Internet and Slack.
I have web application which was developed in .NET 3.5, hosted on Windows server.
Outside people are accessing my web application by creating HttpWebRequest POSTs and passing the browser information along with necessary input values.
How to restrict access to my web application through HttpWebRequest?
You can't really restricted users from calling your site using HttpWebRequest (or 'not a browser', so to say) since all that information about the client machine, like the browser used, can be spoofed.
You have to wonder if you really want to go through all this. Do you want to make your users life miserable (or a least the user experience of your site)? If you do, you might want to use Captchas to make sure there is a real user and not a robot.
I have a website that uses WebMatrix user authentication (login/register pages) and I am making an app in Windows 8 release preview and would like to know if it is possible to authenticate users of my app (let users of my app sign in to my app) if they are registered members of my website? And if they are not, allow them to register through my app - but it appears that remost db connections are not possible in Metro apps - so I don't know what to do. Can somebody please help?
I've been searching for weeks but there still isn't a whole lot of official documentation out there.
You should never ever allow any client or user program to access your database directly (not even read access). People WILL abuse it one way or another and they might try exploits to gain write access if their access is restricted to reading. If you'd like a prominent example, Super Meat Boy did that exactly, and they got lots of database issues and abuse over last year's christmas days (while there game was on (Steam) sale, so they got lots of additional upset players!).
I've never used WebMatrix, so I might be a bit off here, but in general you should have several possible approaches - all being better than doing direct database access:
Use some provided remote access (this might be some extra class or addon or whatever; IF available).
Write your own remote access tool. This would essentially be some special website accepting/returning text or data interpreted by your program. E.g. you could post the login credentials in a HTTP POST request and it could return ok or failed or something like that.
Essentially fake a web browser and access the standard URLs/scripts/systems provided by WebMatrix.
I know the question sounds too vague so let me explain exactly what I want to implement.
I have a WebApplication that many users log into to submit a request, Request in my project is a form that accepts some information from the user and when he click submit, it reflects on the administrator page. then the admin can grant or decline this request. and of course the result need to be sent to the user's 'Pending Requests' page.
this process is all about time so I need a clean and efficient way to show the admin the requests instantly and for the user to see the admin's response instantly. (kind of like facebook notification system).
I hope my problem is know clear. I understand that there are many ways to implement this and I have a very small knowledge about them. But I just want you guys to recommend an effecient way because I'm sure that the good ways to do this is limited.
Thanks in advance everybody :)
I will suggest you take a look at SignalR (https://github.com/SignalR/SignalR). It is a framework developed by a few MS developers for doing long polling/notifications from the server.
Link for webforms walkthrough - http://www.infinitelooping.com/blog/2011/10/17/using-signalr/.
You could also look into using a Timer control. It's a client side control that will cause a postback for ASP.NET AJAX applications. Here's a simple tutorial
http://ajax.net-tutorials.com/controls/timer-control/
What you're talking about is a 'push' notification, where the server would pass a notification to the client (a browser) without the client requesting anything.
This isnt something which HTTP is naturally capable of, however have a read about Comet - this will let you know the current state of what is possible.
You may opt for creating a 'heartbeat' on the client side - a polling mechanism which requests from the server every x seconds, and updates the page when new content is found.
I need a clean and efficient way to show the admin the requests instantly and for the user to see the admin's response instantly.
Instantly is a very strong term and isn't usually very scalable.
For some ideas on how you might implement this I'd recommend you take a look at Wikipedia's Comet Programming page
When a user submit requests I assume that his request is first stored in the database. So on the admin & user part you use ajax which periodically update data from database (for un-approved data), do some google search on ajax auto-update or Javascript's timeout or similar function. The same process will be involved in user part.
I am building a very simple asp.net application that will have a SQL Server 2008 backend.
Some users will be entering data and storing in the database and some users will be viewing data.
The SQL Server 2008 is working with Windows authentication for every user; however, I am unable to get ASP.NET working with Windows authentication yet. Is there a simple way to allow windows authentication with ASP.NET? I found a very convoluted way, but I don't like it.
I will need to audit every action that the users perform.
Should I audit the users at the application level or at the SQL Server level?
Are there already built in methods to do this? If so, how?
On the contrary, I have always found Windows Authentication to be quite easy to set up and relatively painless. Here's some guides:
Setting up
More Setting up
I didn't realize that you could audit what users did at the ASP.NET level. My answer would be to use SQL Server for this one. You'd need to log:
timestamps and user name for every action
do you need to log workstation or location where the actions were performed?
can users go to mul
if multiple locations use this application, consider storing UTC time only
all actions, even deletes, which mean that delete's only get "hidden" from the user, but never erased from the database. Same for edits, the old record should never be changed or taken out of the database.
Your best bet here is to talk to your boss about this one. Auditors can have very specific needs, and you definitely don't want to forget anything. Every situation is different, so be sure to sit down and double check all your requirements and specifications.
Two things:
Here is example on Win auth on asp.net app:
http://weblogs.asp.net/scottgu/archive/2006/07/12/Recipe_3A00_-Enabling-Windows-Authentication-within-an-Intranet-ASP.NET-Web-application.aspx
I suggest you implement a log framework like log4net to log your application. It's simple and easy to use http://logging.apache.org/log4net/download.html
I would do this from the application if it is significant HOW people accessed the data as much as the WHO, but that's quite different from rlb.usa's answer. In my past jobs, it's often been as important to know which application the person changed data from as when/who. If it's primarily for application issues, log4net is a good option.