I am trying to add a feature to a Java/Tomcat web-application to follow the users during their visits on a website A through Javascript calls from the pages of A to a server B (B's applications run on Tomcat 7). The server has a different address from the website.
Each time a user opens a page on A a piece of Javascript is loaded from a url on B. The javascript is served on B by a controller method, which calls HttpServletRequest.getCookies() and looks for a cookie with the right name. If no such cookie is found, a new one is created and added to the response through HttpServletResponse.addCookie(). The cookie mentions the path and IP of B, so they are available there.
The Javascript on A will then regularly send Ajax POST calls to B, where cookies are checked.
While this scenario works fine for many users, I still get a large number of Ajax calls from A to B without any cookie. Not only the cookies I set manually are missing, but also the session cookies set by Tomcat on B. I understand some users may have just set their browser to prevent or block cookies, but there seem to be too many empty requests. Despite a thorough inspection of the logs, I could not find any common feature that would explain the lack of cookies.
Any idea of what I might be doing wrong ?
Related
First off, Thanks in advance to anyone who resolves/helps to resolve this problem. And sorry if this is a duplicate(I couldn't find it anywhere, so posted a new question).
So the main issue is I want my webpage to display an alert message, subsequently from when a user visits the page for 2nd time onwards, so I thought IP logging using cookies would be the most unique thing to do, please do suggest if there's a better thing to use.
Browsing till now, did not get me a way to log IP in cookies. Also, the solutions I found were somewhat similar but they were in PHP, which, I'm not good at.
I would prefer using JavaScript as opposed to jQuery, but all and any help is appreciated.
First off before I give different ways of identify repeated visit and display a message after 1st visit.
I would recommend not using the IP address because there could be multiple machines behind the NAT routers sharing the one IP address, there will also be a the problem of mobiles always changing their IP address because they will also be connecting to different networks.
There is multiple ways of doing this:
I would recommend using either Option 3 or Option 4 so that there is nothing stored on the users machine. It is then much more secure that client side because people can store of JavaScript on their browsers.
Option 1:
You could have a client side local storage by using the HTML5 Web Storage.
HTML5 Web Storage
Before HTML5, application data had to be stored in cookies, included in every server request. Local storage is more secure, and large amounts of data can be stored locally, without affecting website performance.
Unlike cookies, the storage limit is far larger (at least 5MB) and
information is never transferred to the server.
Local storage is per origin (per domain and protocol). All pages, from
one origin, can store and access the same data.
Option 2:
You could go with using a client side cookie, which you would set and remove with JavaScript:
Cookies are data, stored in small text files, on your computer.
When a web server has sent a web page to a browser, the connection is
shut down, and the server forgets everything about the user.
Cookies were invented to solve the problem "how to remember
information about the user":
When a user visits a web page, his name can be stored in a cookie.
Next time the user visits the page, the cookie "remembers" his name.
Cookies are saved in name-value pairs like:
username=John
I've actually done an example of this few days ago.
COOKIE EXAMPLE
Option 3:
You could have a session, which is a good way of checking if you are having users logging into your website/application:
PHP Sessions
A session is a way to store information (in variables) to be used across multiple pages.
Unlike a cookie, the information is not stored on the users computer.
When you work with an application, you open it, do some changes, and
then you close it. This is much like a Session. The computer knows who
you are. It knows when you start the application and when you end. But
on the internet there is one problem: the web server does not know who
you are or what you do, because the HTTP address doesn't maintain
state.
Session variables solve this problem by storing user information to be
used across multiple pages (e.g. username, favorite color, etc). By
default, session variables last until the user closes the browser.
So; Session variables hold information about one single user, and are
available to all pages in one application.
Option 4:
You could use server side cookies (this way it's not stored on users machine), this is a good way of identifying a user (visitor):
PHP Cookies
A cookie is often used to identify a user.
A cookie is often used to identify a user. A cookie is a small file
that the server embeds on the user's computer. Each time the same
computer requests a page with a browser, it will send the cookie too.
With PHP, you can both create and retrieve cookie values.
I'm making a google-chrome-extension for a certain website, and want the browser_action to display the number of notifications a user has received on said website.
Currently, I am using an ajax request to retrieve the HTML from the website/messages page, and then I am using jQuery to count the number of "#unread > li" elements in that HTML (each one representing a new message.)
Now, I take this number and display it on the browser_action icon.
All works perfectly, the correct amount of messages are notified, BUT the user must be logged in on the site (not my site) for it to work properly, otherwise they will think that they have no messages.
I was thinking that I could detect if the user is logged in, and if not display a red ! exclamation mark on the icon. Then, when the user clicks to show the pop-up, it asks them to log in.
However, I have no idea how to actually log the user in to the website using this method: how do I send the credentials across? Or does the website have to support a request like this?
TL;DR
How can I log a user into a website I don't own remotely?
Disclaimer: I've never done a google chrome extension, but based on the rest of your question, it sounds like it's just working with JavaScript like any other web page, so I'll go ahead and answer it.
In any case, working with cookies in JavaScript can be somewhat of a pain:
https://developer.mozilla.org/en-US/docs/Web/API/document.cookie
http://www.perlscriptsjavascripts.com/js/cookies.html
I'm assuming that your server side already works with and expects cookies, so I won't try to suggest any alternatives. That being the case, your server is what needs to validate the cookie, so, IMHO, might as well set the cookie on the server side. If the server handles it, on the JS side, you simply post the username/password to a server-side page, e.g.
$.post("/user/login",{"Username":"foo","Password":"bar"},callback);
That server-side page validates the username/password and then, if successful, generates the cookie and sends a response back to the JavaScript (e.g. {"IsSuccess":true}). Upon receiving a successful response rather than an error, you just start calling the other web services to retrieve your data assuming you are logged in and build out the page.
Assuming that your web services will return HTTP error codes that help you determine a problem with the session, if you get a 401 error code, you take the user back to the login page. If you get a 403 error code, you let the user know they can't access that data...etc., all depending on your app.
Ultimately, JavaScript doesn't know whether a user is actually logged in, so you have to rely on the server to send you information in a way that is understandable so that you can direct/prompt the user as necessary.
[Edit: 2014-11-21]
You didn't answer my other question: what do you get back? If they don't set the cookie themselves at the login, then you need to get back the session token from the response they send...if they don't send you a session ID, you're SOL. If they do send you an session token/session ID, then you need to know what to name it (e.g. PHP uses something like PHPSESSID as the cookie name, but it can be whatever the coders of that domain decided on). Beyond that, you have to be able to set the cookie for THAT domain name (3rd party cookie). This may have mixed results depending on the user's settings--if they block 3rd party cookies--however, since this is a google extension and not a website, maybe it's able to bypass that kind of restriction. I know that FireFox's developer toolbar is able to manipulate cookies for all domains, so it would be a reasonable assumption you would be able to as well.
I need a primer web/javascript security.
According to How to use an HTML/JavaScript client for Windows Azure Mobile Services, in javascript on the client side, after including a link to MobileServices.Web-1.0.0.min.js you're supposed to create a client like this:
var MobileServiceClient = WindowsAzure.MobileServiceClient;
var client = new MobileServiceClient('AppUrl', 'AppKey');
which means including my AppKey in the javascript on the page. Should I be worried about the AppKey being public?
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in. The usefulness of this is somewhat reduced with a cross-origin resource sharing whitelist, but what's to stop someone with this information from adding javascript to the page and executing arbitrary operations on my backend database? Restricting table permissions to authenticated users wouldn't help in this scenario.
Do I need to be concerned? What do banking apps do about this sort of thing?
In the same link which you shared, application key is defined as a not safe mechanism to authenticate users - A unique value that is generated by Mobile Services, distributed with your app, and presented in client-generated requests. While useful for limiting access to your mobile service from random clients, this key is not secure and should not be used to authenticate users of your app.
More over when you enable some authentication on all the endpoints either using ACS or through Open Authentication, if you main ASP.Net/PHP etc page got authorized, then browser is going to handle federation of identity through cookies for next on-going calls till your session ends.
In most of the applications having HTTPS would protect from Man in middle attacks. Also strong encryption logic on cookies along with very specific expiry times would increase the bar of security. Also IP address based checks would definitely help in improving security.
ramiramilu's answer covers most of the question. There's one more thing which I'll add:
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in
Yes, someone can add a breakpoint and find out the value of the X-ZUMO-AUTH header which they're sending. But the value of that header is specific for the logged in user (in this case it would be the "attacker" [him/her]self) - it wouldn't be able to get information from other people out of that header. And there are even easier ways to get the value of that header (just browse to https://<mobileservicename>.azure-mobile.net/login/<authProvider> and after entering your credentials you'll see the header encoded in the URI).
Just want to get input from people who know. I was considering CSRF vulnerabilities, and the seemingly the most popular method I know to fight against it. That method is to create a token in the returned html and adding a cookie with the same value. So if a script tries to do a post they would have to guess the token thats embedded in the web page for it to be successful.
But if they're targeting a specific website why can't they just use a script that
Calls a get on the page (the cookie will be returned even though the script can't access it)
Parses the html and gets the token
Calls a post with that token in it (the cookie that came back will be sent back)
They've successfully submitted a form without the users knowledge
The script doesn't need to know the contents of the cookie, it's just using the fact that cookies get sent back and forth all the time.
What am I missing here? Is this not possible? I think this is pretty scary if you think about it.
Below this line is not required reading to answer the question :)
This vulnerability banks on the fact that authentication is done based on cookies, which I think is the main way authentication is currently occurring.
Another solution I can think of is making authentication be on the page level. So
when they log in the returned html will have that token in it. every link that they click contains that token so when the web server gets a request it has a way to identify the user/session. The problem with it is that if they use any navigation other than that they will be 'unauthenticated'(e.g. type in a url) , also it doesn't look nice in the url because it would probably look something like this:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
But I do understand that if safety is more important, then a pretty URL is second place.
I don't know everything about cookies but what if user agents were a little more careful with their cookies?
For example, what if the cookies sent depended on the tab? We all surf using tabs by now, right? so what if the scope of the cookie was the tab? so if i have my banking site open on tab 1 and i'm surfing on tab 2, any scripts calling gets/posts on
tab 2 will only send the cookies accrued in tab 2.
Or what if cookies were stored / domain. So while I'm on example.com any cookies that come back go into the example.com cookie collection. and then when i'm on www.mybankingsite.com all the cookies get put into the mybankingsite.com collection. So if I go to example.com and it runs a script that calls a get/post the user agent will only send example.com cookies. This is different than sending the cookies of the requested domain. E.g. if a script calls a get of mybankingsite.com within a web page of example.com the user agent will not send the mybankingsite.com cookies.
I know i have no control over what user agents do, but I'm just exploring possibilities
So I think the problem here becomes the attacker's attempt to get the page's contents. To get the authenticated user's page, the attacker needs to be able to send a request on their behalf and read the contents. AJAX won't send cross-domain requests, iframes won't let you read the response. I am struggling to think of other ways in which an attacker would get the contents first.
A more likely hack is using clickjacking to have the user just submit the form. This technique doesn't seem too likely. (caveat: it's security, we can always be wrong.)
Does anyone care to share some code on this issue as I just hacked my own site (Not in production) with CSRF. All I had to do was the following
At: www.badguy.com/ write the following html
img src="www.goodguy.com/secure/user/delete/5">
What this does
So the admin goes to to www.badguy.com/ and the the image makes a request to
www.goodguy.com/secure/user/delete/5 from the users browser so the admin unknowingly just deleted a user. If you create a loop your in some trouble. Expect I never delete data just change its status :) but still I don't like the looks of this.
The CSRF token has to be unique per session. If a malicious server requests the same page, they will get a different token. If they try to request the contents of the page via JavaScript on the client's machine, the same-origin policy will prevent them.
I wrote a web page that displays images from several servers on my network via simple img tags with appropriate href values. The servers require authentication before they will send the images.
It works alright, except on first load the page presents the user with a series of password prompts (one for each server). The user can select the "Remember my password" checkbox, and then subsequent refreshes of the page work without prompting, with correctly updated images. That is, until someone closes out the browser, after which a new set of prompts awaits anyone who opens the page again.
All of the credentials needed are known beforehand, and I don't care if someone could read them in the page source, since this page is in a protected part of an internal intranet site. Everyone with access to this page knows the passwords anyway.
The only browser we're allowed to use is IE 7, so I don't care about compatibility with other browsers at the moment.
Is there any way I can use JavaScript (or some other client-side code) to automatically answer those prompts so the user never sees them?
Thanks very much, in advance.
You can include the authentication in the URL:
<img src="http://paulfisher:tastybacon#internalwebs/path/to/image.png">
Where, of course, paulfisher is my username and my password is tastybacon.
No, javascript can't do this. Here are a couple of options that I've used before to solve this problem:
Change the authentication on the other servers to be either anonymous or integrated.
Proxy in the images: On the server serving the page, add another page that takes in the URL of the remote server. This new page makes a webrequest to the other server and streams the image back. The webrequest can plug in the correct credentials.
Depending on the servers' DNS names, it might be possible to share an authentication cookie across all of the servers. Then you could set up some kind of module on all of the servers to allow the shared authentication.