I'm coding a php framework to add functionalities for a second party website, which is not ours and don't have control at all.
This website has Oauth 2.0 authorization for its clients and save access token in cookies. As I must interact with their own public API, I need to read that token to make my requests.
Question is.. which is the best strategy to code that? I'm not a php programmer but very proficient in C++. I wonder if its possible to open website inside an IFRAME and read cookies with javascript, am I making any sense????
If you really want to do that, open the site in a hidden iframe, the page that the iframe loads should have something like
window.parent.getCookie(/* the cookie value*/);
So you can use the getCookie method is in your main site and read the external site cookie, then you can use ajax to send the cookie value to your script, and work with it or save it as a cookie, you can also use javascript to save the cookie.
EDIT: Remember cookies should never store sensitive data, even in your own site.
Related
Imagine a scenario where you own mysite.com, and it loads javascript from an exterior domain such as adsprovider.com/ads.js.
Can adsprovider.com's javascript then perform an ajax call to mysite.com and attempt to retrieve the user's session data? If so, how can you protect your users against it?
Can adsprovider.com's javascript then perform an ajax call to mysite.com
Yes. The origin is defined by the URL of the HTML document the script is loaded into, not by the URL the script itself is loaded from.
retrieve the user's session data
Only if the session data is exposed through HTTP. Stuff you never give to the client is safe (but there is probably going to be quite a lot of session data that should be kept private between your server and the user).
Note that the script can read document.cookies and steal the session token too (unless the session token is sent with the httponly flag on).
If so, how can you protect your users against it?
Sandbox the adverts in iframes hosted on different origins.
Fortunatly, an Ajax call for your session data can't be directly request from external server.
You can load javascript from a CDN external source of course, but the script run from your own domain, and access to your server is not possible from outside.
Otherwise there would be a lot of security problem.
Also keep in mind that javascript is client side.
You can check Same-origin policy and CORS for more info on this topic.
I’m adding a notification to my website about a new feature that has been implemented. The notification is near the top of the website, in an eye-catching place to get people’s attention. Using jQuery, I wrote a small function that hides the notification when the user chooses to. If the user chooses to hide the notification, I want it to be hidden permanently for the remainder of the visit and on future visits to the website.
What would be the best way to make sure that when they return to the website later on, the notification is hidden? I thought about sending an AJAX request that creates a cookie when the user initially hides it, then checking for the cookie when the page loads, but I’m not sure if that’s the best way to do it. I don’t want to hide it based on IP address because I’m afraid that two users on the same network but different computers might access the website, and one will miss it, but maybe I’m being too paranoid. Any ideas on the best way to do this?
Why not just create/read the cookie with javascript?
I would suggest using javascript to set/read the cookie as well. Since you're already using jQuery I would suggest the jquery.cookie plugin. The only reason for doing an AJAX request to save the user's preference is if your user is logged into the site and you want to store their preference in a database or some other persistent storage so that whenever they are logged in they don't see the message about your new feature.
If the server does not need to be aware of the value of the cookie I would suggest you use localStorage instead.
localStorage exists on the client and does not get sent with the $_COOKIES header to the server.
More can be read about localStorage here
And even more can be read as per why you would want localStorage over cookies for client side data here Local Storage vs Cookies
I have a "Client Center" on my website which is only accessible via HTTPS. I'm currently using a single session cookie to track PHP session variables such as User_Authenticated, Client_ID, etc once they log in.
I want to change the links on my navigation bar from "Login" to "Logout | Client Center" once they have logged in. This is easy enough, but most of my website has absolute links that point to HTTP instead of HTTPS. I could make all of my links relative and that way hopefully keep them on HTTPS once they've logged in, but my site is graphics-intensive and I can't guarantee that they'll stay on HTTPS (if, for instance, they type http://mysite.com on their browser after logging in).
My question is as follows:
1) Is there a risk in passing this cookie over HTTP? I hear that it can be intercepted and spoofed. That would be bad!
2) Can I use two cookies, one which is a secure_only cookie which contains their credentials, and another which just lets the browser know if they're logged in or not, for the links on my navigation bar? Is it possible to use multiple sessions simultaneously like this with different cookies?
I've also heard about using a database-based session management system, but for now that is way over my head. I'm new to PHP and MySQL (this is my first site).
Thanks in advance!
You can do what you want, using a second cookie. Then you can use the session cookie for HTTP and HTTPS pages (to get the login state), but make the authentication only with the second HTTPS-only cookie.
I wrote an article, describing how to separate this two concerns, maintaining the session and authentication. It's a good thing to do, even if you decide to use HTTPS for the whole site.
I would think about enforcing HTTPS for the whole site though, this would make your life easier. If your site has not very high traffic, it should be no problem for todays servers.
Authentication cookies being passed over http is a bad idea. That's the problem that firesheep brought to light, and the reason that Google, Facebook and Twitter, among others, now encourage (or require) https all the time.
If you're worried about sesion hijacking on your web site then you should be enforcing https for every page and asset that needs to be secured. Ideally enforce https for all assets to avoid annoying borwser warnings about mixed security on the page.
You can use this
http://systembash.com/content/force-https-ssl-access-url-apache/
If I had a user logged onto my site, having his id stored in $_SESSION, and from his browser he clicked a 'Save' button which would make an AJAX request to the server. Will his $_SESSION and cookies be retained in this request, and can I safely rely on the id being present in the $_SESSION?
The answer is yes:
Sessions are maintained server-side. As far as the server is concerned, there is no difference between an AJAX request and a regular page request. They are both HTTP requests, and they both contain cookie information in the header in the same way.
From the client side, the same cookies will always be sent to the server whether it's a regular request or an AJAX request. The Javascript code does not need to do anything special or even to be aware of this happening, it just works the same as it does with regular requests.
If the PHP file the AJAX requests has a session_start() the session info will be retained. (baring the requests are within the same domain)
What you're really getting at is: are cookies sent to with the AJAX request? Assuming the AJAX request is to the same domain (or within the domain constraints of the cookie), the answer is yes. So AJAX requests back to the same server do retain the same session info (assuming the called scripts issue a session_start() as per any other PHP script wanting access to session information).
Well, not always. Using cookies, you are good. But the "can I safely rely on the id being present" urged me to extend the discussion with an important point (mostly for reference, as the visitor count of this page seems quite high).
PHP can be configured to maintain sessions by URL-rewriting, instead of cookies. (How it's good or bad (<-- see e.g. the topmost comment there) is a separate question, let's now stick to the current one, with just one side-note: the most prominent issue with URL-based sessions -- the blatant visibility of the naked session ID -- is not an issue with internal Ajax calls; but then, if it's turned on for Ajax, it's turned on for the rest of the site, too, so there...)
In case of URL-rewriting (cookieless) sessions, Ajax calls must take care of it themselves that their request URLs are properly crafted. (Or you can roll your own custom solution. You can even resort to maintaining sessions on the client side, in less demanding cases.) The point is the explicit care needed for session continuity, if not using cookies:
If the Ajax calls just extract URLs verbatim from the HTML (as received from PHP), that should be OK, as they are already cooked (umm, cookified).
If they need to assemble request URIs themselves, the session ID needs to be added to the URL manually. (Check here, or the page sources generated by PHP (with URL-rewriting on) to see how to do it.)
From OWASP.org:
Effectively, the web application can use both mechanisms, cookies or
URL parameters, or even switch from one to the other (automatic URL
rewriting) if certain conditions are met (for example, the existence
of web clients without cookies support or when cookies are not
accepted due to user privacy concerns).
From a Ruby-forum post:
When using php with cookies, the session ID will automatically be sent in the request headers even for Ajax XMLHttpRequests. If you
use or allow URL-based php sessions, you'll have to add the session id
to every Ajax request url.
It is very important that AJAX requests retain session. The easiest example is when you try to do an AJAX request for the admin panel, let's say. Of course that you will protect the page that you make the request to, not to accessible by others who don't have the session you get after administrator login.
Makes sense?
One thing to watch out for though, particularly if you are using a framework, is to check if the application is regenerating session ids between requests - anything that depends explicitly on the session id will run into problems, although obviously the rest of the data in the session will unaffected.
If the application is regenerating session ids like this then you can end up with a situation where an ajax request in effect invalidates / replaces the session id in the requesting page.
That's what frameworks do, e.g. if you initialize session in Front Controller or boostrap script, you won't have to care about it's initalization either for page controllers or ajax controllers. PHP frameworks are not a panacea, but they do so many useful things like this!
put your session() auth in all server side pages accepting an ajax request:
if(require_once("auth.php")) {
//run json code
}
// do nothing otherwise
that's about the only way I've ever done it.
Say I have an ASP.NET webpage and I also have a PHP Blog/BBS/Website. I want all logins to be done via the ASP.NET webpage. The ASP.NET Session State is stored in SQL. Is there any way I can read/decode the Session State from PHP to tell if a user is logged on if I have the Session State cookie?
I don't think there's a supported way. You could reverse-engineer the store, but the database format may change with next .NET service pack and youe a'd be screwed then.
The only safe way would be to implement your own session state provider so you could guarantee that the database format doesn't change.
If all you need is to verify that the user is authenticated, it would be probably easier to send the user an encrypted cookie with the username and decrypt it in the PHP app.
I have never tried this but if you provided a simple web service that is part of your asp.net application but only accessable from your PHP site. You should now be able to read anything that is in session via the web serivce.
this is looks tricky, but try reading here. the issue here is know the way in what asp encodes and save the session, if you can read that format, this may help.
another way I'm thinking is to create a request to some "login" page form asp to php, where you send the login credentials and the php file creates the session, but this could be not secure if you leave it open, and also could be slow, since another request is necessary.
on the other hand I saw few sites, where once you are logged in, for example in the main site and you want to go to the forums, you click on some link that submit a form to the php login page (credentials are "harcoded" for that user in that session) and the php page login you like the "regular" behavior.
hope to be clear
Unless you specifically need full access to the entire asp.net session state, you may be better off just storing the particular pieces of information that you know both apps need to share in a shared database or file directly.
That way you can ignore most of the complexities of an asp.net session and just pick and choose the specific pieces data your apps need share with each other.