I found a strange thing when i'm coding a net-spider to a specific website.
I used fiddler and chrome(as well as other web-browsers) to log-in a website(HTTP, not https) and get all package(as well as the cookie) that sent and received:(
first package 'Get' to request the log-in page and the cookie, then use the cookie received to request verification code and some other pics. and then send login request with userid, password and verification code to server and server response with correct info)
Then I log-out and Clear all Cache and Cookie and use Fiddler to Relay(Simulate) the whole process (Since I know all packages' format that i should send): request the log-in page to get cookie, use the cookie to request all pics( auth code image included), and then use the cookie and auth code to request login(userid and password are correct)...but failed.
I'm sure the failure is not caused by invalid userid or password or auth code, and i believe there is nothing special on the front-end(html,script are checked), but it puzzled me a lot how can the server tell i used browser or not in back-end..
I'm not request anybody to solve the specific problem. i'm just wanna know DOES ANYONE HAS HAD SIMILAR PROBLEM i described?
the specific website is not important and i must say the whole practice is completely harmless! i'm not doing any hacking stuff, on the contrary it will help some people.
======================================================
I've finally figured out the reason: the log-in page has a hidden input() and i carelessly overlooked that since its value looks almost the same every time. Web server can not detect replayed log-in attempts if we simulated all necessary HTTP request packages.
Thank you guys~
Servers cannot magically tell whether they're talking to Fiddler or not.
If Fiddler and your client are sending the exact same requests, that means that the server in question is using a "one time token" (sometimes called a nonce) in its login form. If the server ever sees the same token again, it rejects the logon. Sometimes the nonce isn't sent directly, and is instead used in the computation of a "challenge-response" as occurs in authentication protocols like NTLM. In other cases, the nonce is a CAPTCHA, which helps prevent you from using a bot to automatically log in to a site like this.
Unless you can share more details of the target site (or a SAZ file of the login process), it's unlikely that folks will be able to help you.
Related
I'm developping a webapp linked to a CAS server with phpCAS. Up to now everything was going well, I was able to access my app after the CAS authentication. I'm now supposed to implement a logout feature : when someone logs out of the CAS server, it sends logout request to all apps opened for that session.
The problem is my app doesn't seem to receive that request. I contacted the adminstrator who told me that he can see the request leaving the server. He then asked me to confirm him that my server received that request.
And here is the problem : I have no idea how to see if the server received the logout request (a json file...apparently a POST Method is used to send the data to the address of my app...as you see, I have no idea what I'm talking about.). I've been searching for days now and I'm totally in the dark. I tried to use tcpdump. I see a TCP F Flag when I logout of the CAS server so it seemed first like a good thing. But I have no idea how to see if my server has received a logout request.
Hoping that someone can help me...
Thanking you in advance.
And here is the problem : I have no idea how to see if the server received the logout request
You need to design some kind of filter/interceptor that sits in front of your application and intercepts all requests. This filter should examine the request body to see if the request is indeed a logout request. If it is, parse and consume the request body and begin to logout and remove the application session accordingly.
...with a little bit of searching and effort, it looks like phpCAS can handle logout requests on its own:
https://github.com/apereo/phpCAS/blob/master/docs/examples/example_logout.php
apparently a POST Method is used to send the data to the address of my app
Not "apparently"; rather, exactly. According to the docs:
The CAS Server MAY support Single Logout (SLO). SLO means that the user gets logged out not only from the CAS Server, but also from all visited CAS client applications. If SLO is supported by the CAS Server, the CAS Server MUST send a HTTP POST request containing a logout XML document (see Appendix C) to all service URLs provided to CAS during this CAS session whenever a Ticket Granting Ticket is explicitly expired by the user (e.g. during logout). CAS Clients that do not support the SLO POST requests MUST ignore these requests. SLO requests MAY also be initiated by the CAS Server upon TGT idle timeout.
And then here is the actual payload.
We are developing a MVC application using .Net identity. We have created register and login systems. Now we are trying to add some security.
My friend have logged in to application and session cookie have been created. With an extension, i have created same cookie in my machine and i have successfully logged in. How can we prevent this?
We have tried adding [ValidateAntiForgeryToken] and #HTML.AntiForgeryToken() but not pages are throwing
The required anti-forgery form field "__RequestVerificationToken" is not present.
Exception. We think we are missing something. What is the right way to do this?
I don't think this token does what you're trying to use it for. According to this StackOverflow question's accepted answer, it's actually for preventing cross-site request forgeries, not for preventing hijacking of browser sessions.
Your main question appears to be:
With an extension, i have created same cookie in my machine and i have successfully logged in. How can we prevent this?
What you need to bear in mind is that you have been able to get hold of a security cookie from another machine. In the "real world", that security cookie would be transmitted over a secure channel (such as https), such that one user should have no way of getting at another user's cookie. If a user "a" managed to get hold of the cookie from user "b"'s computer without user "b" performing any deliberate action, then user "b"'s computer is already terminally compromised.
Although I commend you for trying to work around this, if a user were capable of getting hold of another user's cookie there's a fairly good chance they'd also be able to get hold of pretty much anything else too. You could check that the browser identification string always matches, or that the IP address the requests come from doesn't change, but both checks are possible to circumvent if someone is determined enough.
I've just started working on an aspx web from login page for AspNet.Identity.
I have my fields, username and password (textmode="Password") and a submit button (asp:button) as usual with my code behind to do login, etc.
My question is, when my user clicks submit, how is the password sent to the server? Do I need to be on SSL to ensure that the password isn't sent in cleartext?
Edit
StackOverflow's login page isn't over HTTPS - how do they (and other sites that don't use HTTPS) manage password transmission?
One can say that all data submitted from the browser is sent in cleartext (that is, neither browser itself encrypt it, nor when data arrives to your server-side script it requires decryption). All the encryption (if any) is performed at the protocol level.
Plain HTTP doesn't encrypt any information sent over it, which allows for simple inspection (man-in-the-middle attack, eavesdropping). On the other hand, HTTPS creates a secure channel over an otherwise insecure network and protects from said attacks reasonably well.
One caveat to that is using GET to send data to the server. This information can easily end up in server logs.
Depending on the form method GET or POST values are sent to the server.
By default in asp.net the form method is POST so it is send in the body of the request.
If the form method is GET then it sent in the url.
Edit 1
When you use HTTPS the channel is secured. But some time it can be slower than HTTP because HTTPS requires an initial handshake which can be very slow.
Some useful links
Difference between http and https
HTTP vs HTTPS performance
Main problem is that if anyone is able to listen to the traffic from your client to your server, then they will also be able to manipulate what your server sends to client. This issue invalidates all attempts to do some javascript magic to hide it out will be lost effort.
In other words, there is for the time being only SSL to help you out.
I was using Fiddler see on-the-field how web sites use cookies in their login systems. Although I have some HTTP knowledge, I'm just just learning about cookies and how they are used within sites.
Initially I assumed that when submitting the form I'd see no cookies sent, and that the response would contain some cookie info that would then be saved by the browser.
In fact, just the opposite seems to be the case. It is the request that's sending in info, and the server returns nothing.
When fiddling about the issue, I noticed that even with a browser cleaned of cookies, the client seems to always be sending a RequestVerificationToken to the server, even when just looking around withot being signed in.
Why is this so?
Thanks
Cookies are set by the server with the Set-Cookie HTTP response header, and they can also be set through JavaScript.
A cookie has a path. If the path of a cookie matches the path of the document that is being requested, then the browser will include all such cookies in the Cookie HTTP request header.
You must make sure to be careful when setting or modifying cookies in order to avoid XSS attacks against your users. As such, it might be useful to include a hidden and unique secret within your login forms, and use such secret prior to setting any cookies. Alternatively, you can simply check that HTTP Referer header matches your site. Otherwise, a malicious site can copy your form fields, and create a login form to your site on their site, and do form.submit(), effectively logging out your user, or performing a brute-force attack on your site through unsuspecting users that happen to be visiting the malicious web-site.
The RequestVerificationToken that you mention has nothing to do with HTTP Cookies, it sounds like an implementation detail that some sites written in some specific site-scripting language use to protect their cookie-setting-pages against XSS attacks.
When you hit a page on a website, usually the response(the page that you landed on) contains instructions from the server in the http response to set some cookies.
Websites may use these to track information about your behavior or save your preferences for future or short term.
Website may do so on your first visit to any page or on you visit to a particular page.
The browser would then send all cookies that have been set with subsequent request to that domain.
Think about it, HTTP is stateless. You landed on Home Page and clicked set by background to blue. Then you went to a gallery page. The next request goes to your server but the server does not have any idea about your background color preference.
Now if the request contained a cookie telling the server about your preference, the website would serve you your right preference.
Now this is one way. Another way is a session. Think of cookies as information stored on client side. But what if server needs to store some temporary info about you on server side. Info that is maybe too sensitive to be exposed in cookies, which are local and easily intercepted.
Now you would ask, but HTTP is stateless. Correct. But Server could keep info about you in a map, whose is the session id. this session id is set on the client side as a cookie or resent with every request in parameters. Now server is only getting the key but can lookup information about you, like whether you are logged in successfully, what is your role in the system etc.
Wow, that a lot of text, but I hope it helped. If not feel free to ask more.
I'm writing a mostly ajax-driven web application and I'm looking at how to protect the user from CSRF attacks. I'm planning to run the pages of the application where the user is logged in to do his work in HTTPS mode.
Does running the page on HTTPS work to protect against CSRF attacks?
No, running a page on HTTPS does not protect it from CSRF. The fact that the communications between the browser and server is encrypted has no bearing on CSRF.
I suggest reading the OWASP guidance on preventing CSRF.
A general, golden rule woule be:
Never trust that the incoming client request is a legitimate one. Be always suspicious and assume that the request could be maliciously forged.
Few specific rules beyond the mentioned OWASP article:
if your data needs authentication/authorization, avoid generic interfaces on the server, like the CRUD interface. easy to code, difficult to authorize specific requests coming from clients. instead, offer a SOA-style interface with explicit methods dedicated to specific use cases where you will have direct control over requests and their parameters.
http://msdn.microsoft.com/en-us/library/ms954638.aspx
even if the framework provides some control over the request validity (ASP.NET viewstate), check again if the user is authorized to pass the set of incoming parameters.
I'll try to explain:
• HTTPS prevents from someone on the same network to get your Session KEY/ID. Say they got your session identification key/id, then they can fake your IP if needed and send all POST requests they want back to server.
With HTTPS all HTTP body (the whole "HTML") is encrypted. Hence no session key is being guessed.
• What happens in CSRF is that the user is clicks a link, which also creates a request to another server and communicates with it, say using user's session but NOT ON THE SAME NETWORK. Means that it cannot listen to what the server replies back to user. If the attacker knows the replies and can communicate them, voila. No problem. No money's left on the user account. But if the server sends a random token to the IP associated with the session, then the attacker cannot guess it on a different network!
The best possible solution is to include secret tokens - to identify the user - in form submissions to the server. Refer to the following links for more information.
http://en.wikipedia.org/wiki/Cross-site_request_forgery
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
http://seclab.stanford.edu/websec/csrf/
https doesn't safeguard your app from xss attacks. You need csrf token which should be (1) encrypted (2) expiring after some time (3) CSRF token based on page & time