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.
Related
I have an issue with Worklight 6.1. I will describe the scenario below:
User logs in the app and a new session is created for him. Then he stays inactive for some time until the session times out. When clicking on a button, an HTTP request is performed towards an HTTP adapter. However the Worklight server (Liberty) sees that there is no active session for this user and returns the appropriate response that the user is logged out and the user is redirected to the login page. This is correct up to here.
When the user logs in again and is redirected to the landing page, the previous request seems to have been cached and is performed resulting in an error as the necessary information is not yet available. How can I prevent this request from occruring when the user re logs in?
Thank you.
it's not possible to prevent the original request from re-sending after authentication.
The logic of the authentication and the logic of the application are separated and the result of a successful login will be the invocation of the original failed invocation.
What you can do is add to the adapter procedure implementation the logic that makes sure all the information is available, and if not - send an empty response to the client and in the client do whatever you want to do when the data is missing.
This should be done for all the procedures that rely on the session state.
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.
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 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.
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