I have come across a strange requirement during Security Review where I have to prevent username and password is being sent over HTTP GET in asp.net web forms.
Scenario is like this.
We have simple asp.net login form with user name, password and Submit button(POST method). During security review, the security tester changes the Form method to GET using some proxy tool(Burp Suite),then the user name and password is sent over as query string.
GET /Login.aspx?_LASTFOCUS=&_EVENTTARGET=&_EVENTARGUMENT=&_VIEWSTATE=''&_SCROLLPOSITIONX=0&_SCROLLPOSITIONY=0&__EVENTVALIDATION=%2FwEWCgKm973fCgKOieLQt9kH6PhK0wq%2FpfP8pXG%2FF&%24txtUser=abc#abc.com&txtPassword=1233&%24btnLogin=Login
As per the security testing team the GET (form method changed to GET using proxy tool) method should not pass the user password in query string.(as per my understanding GET will always pass value as query string even if it is password field)
An easy way to acheive what you need is to speficy server side to only look at the posted values server side and ignore the query string items, for example by using
Request.Form["foo"]
Instead of
Request["foo"]
Or
Request.QueryString["foo"]
There is no security reason for this, really you just want to be using SSL.
Related
Problem statement:
Hi. I have some secured data which I want to expose through Web API and ASP.NET Identity mechanism. I want to use out of the box classes of ASP.NET Identity. I take a payment manually and change a value in the table. But there are cases where the user will share his username + password with some other guys so that the others can access the same content without paying anything.
Work plan:
So, I have extended the AspNetUsers table with a column named ApplicationToken (varchar). After successful login, I want to generate a token, update the field of the user's row in the table, and add this value as a claim information and send back to the client app. Now, when the user requests for a paid content, my client app will send the token also. So, somewhere in my server side codes, I need to check this ApplicationToken with the Database token value. If both are equal, I allow the request to proceed, otherwise I will send 401 Unauthorized and tell them to login again.
Implementation options:
After studying and searching, I found the below options to implement:
Create Custom Authentication Filter attribute so that I can grab the claims send from the client and do my required validation
Create a base class of the secured API and get the claims there and do my required validation.
Go for different Jwt based implementation where I should have access in both issuing and checking the Json Web Tokens.
If you have any other options, I would be very glad to hear those.
My question is, which approach is better to proceed. I have enough time to implement, so time is not a factor here. Thanks.
I need to add some authorization/authentication logic to an existing web form. Essentially, a user will enter their email address, then I check that email address against an existing database, and if it exists I send an email to that address containing an activation link to the web application. Once the user clicks that link, I want their client to be considered "authorized" for a short amount of time (like their browser session, for instance). They can then access certain pages until their authentication expires.
This would be extremely easy to do using custom ASP.NET forms authentication, but after doing some research there seems to be many more options today in terms of authorization/authentication. Things like ASP.NET Identity 2, Katana/OWIN, and more, it is getting to be quite overwhelming.
I'm looking for suggestions on the simplest way to currently implement something like this in an MVC4 application. I should be able to upgrade the application to MVC5 if necessary.
This is essentially the same process most password resets use, so you can pretty much approach it the same way:
Create a table to track these "authentications". You pretty much just need a column for the token, a column for a datetime, a column for a boolean. The datetime can either track the creation date and time of the token, which you'd then use in your code to calculate if it's too old based on your desired time frame, or you can track the expire date and time of the token and then simply check in your code if that expire date has passed or not. The boolean would track whether the email address has been confirmed, via having followed the link with token in the email you send out.
In your initial form, you collect the email address and combine this with a salt and one-way encryption to produce a token. You send the email with a link that includes that token. Save the token and the appropriate datetime value in your table.
On the page the user goes to after clicking the link, you use the token from the URL to lookup the matching row in your table, check the date value, and set the boolean to true for confirmed. Then, store the token in Session.
On each subsequent request, check 1) there's a token in Session and 2) that that token is still valid (lookup it up in the database and check the datetime and confirmed status). If the token doesn't exist or is no longer good, delete the row, remove the token from Session, and redirect the user to the original email address collection form. Otherwise, allow the user to view whatever content is there.
The simplest way, is to have a database table for the users, and do checking for user authentication and if it's use FormsAuthentication.RedirectFromLoginPage, The identity framework gives you more options for security and encryption also for group and role management.
http://msdn.microsoft.com/en-us/library/ka5ffkce(v=vs.110).aspx
I have implemented basic aunthentation from url http://www.asp.net/web-api/overview/security/basic-authentication. Now I have a question that how i send the basic aunthentation to user on login or on register action that is inside controller.
in short how i create a token and integrated in responsed header.
Kindly help me i have spent more then 4 hours on it.
Thanks
The token is created manually from the credentials users provide.
This means that you have to show a login form in your ios application, gather the username and password and then append the authentication header to each request.
The name of the header is Authorization.
The value is computed as follows. You take the username + ':' + password and encode such string to a byte array. Then you get base64 out of the array.
The value of the header is basic [base64ofusernamepassword] where the [base64ofusernameandpassword] is replaced by the base64 of the username and password you just computed previously.
The exact way of appending custom headers to requests can vary depending on the client technology but it should be easy, no matter which technology is used.
I'm implementing a SMS verification system. this system is provided by a third party company. it can be done by using both GET and POST. that both works perfectly.
Using get:
http://srviceprovider.com/sms.aspx?text=SomeText&To=ReceiverPhoneNumber&from=SenderPhoneNumber&username=MyUserName&Password=MyPassword
that is simply giving out my credentials
and the second way the provider show in its example is:
Post using:
Response.Write();
this looks better than the first one. but still one can access the username and password. I was wondering if there is a way to post data from server (not client side) and may be using sql queries.
Use SSL communication. Google it.
You should not be sending or even storing plain passwords in your database. It must be encrypted everwhere using some encryption algotithm like SHA. For eg. Password abc will be encrypted and saved as 123. Password can be encrypted at the client side itself and then sent to the server. Even if anyone sees the password value (123) in the string or in the database table he would not be able to use it in the password box because the encrypted value of 123 will be something else like xyz.
Read more about SHA algorithms and you will yourself get to know everything.
Cheers and all the best !
As per my understanding you wish to post to a webserver but not from your client side. You can make use of WebRequest class (at server side) to post data to the 3rd party's web server. Futher if you wish to make the entire process aynchronous you can make use of Win Services/WCF Services to post data on some web server. Here you will first just update the fields/flags in the db tables using queries fired from the client side. Next your win/wcf service will pick those records from the tables, form the required query and finally will POST it on some web server. For more information on WebRequest class you can go through this link.
I have 2 applications, each in different domains. When a user comes to the first application, clicks a link, the user is sent to the second application.
My problem is as follows: I need to persist a sessionId from the first application to the second application. Simple enough but here's the catch. I can't use query string and I can't use cookies(since in different domains). I was thinking, is there a way to insert custom values into HTTP Headers or set some form values on an intermediate page which would then POST to the second application? So the process would be as follows:
User clicks a link on the first page, this takes the user to an "intermediate" page, this "intermediate" page sets a sessionId value in the form or http Header, then the "intermediate" page sends the user to the second application via a POST where the app will have the sessionId.
I can't use a Server.Transfer since the app is not on the same server. Help?
This is how Microfot tried to do it Does Issuing Passports Make Microsoft a Country?.
You could try and make a secure SOAP or XML request with a secure token referencing a session id you stored for the user in a shared database. You could then load the user's session based on that session id stored in the db if a match is found.
One way that you could do it is to use webservices. Before the user is to switch sites, you could give the user an unique authentication token that has been agreed upon prior to leaving.
Another thing you could do (this is not a great solution, but it works) is to use frames, and to send the child frame information through javascript (login information). I really don't like this method, because it presents so many problems that its best avoided.
What I mean:
Web services: Communicate with the other site to say "this user is currently logged in here," you can do this at login (depends how much you trust the other domain), or you can do it when the user requests to leave
Giving the user an authentication token: You can post it as a form element. Or if you had an agreement with both domains you could send it to a URL that could later be interpreted as a rediection service+authentication token confirmation portion. I.E.: domain.com/page/token+pageid-mixture
Use OpenID. It's designed for this purpose (common authentication to web sites on multiple domains). The protocol's been under development for years and has probably encountered and solved a lot of the problems you'd be likely to run into if you roll your own solution.