I am making app that takes a screenshot of a URL requested by the user. I want to make it as transparent as possible when sites that require username and passwords are in question.
For instance, if user wants to screenshot its iGoogle page, he will send the server URL but, the screenshot will not be the same as what he sees on his screen.
Is there any way to do this ? I guess that in such cases I will have to actually request screenshot from the user. Perhaps user can even deliver me his cookie for that domain.
Any thoughts ?
Ty.
Yes, in most cases you'll need user's cookies.
If site uses regular cookies, you can create bookmarklet that reads document.cookie. This will not work with httpOnly cookies which are used increasingly often for sessions.
Some sites limit sessions to certain IP, and in that case you can't take screenshot without proxying request through user's computer.
If you can get user to use bookmarlet, an interesting trick would be to read and send DOM to your server:
image.src = 'http://example.com?source=' +
escape(document.documentElement.innerHTML);
For HTTP authentication easiest solution would be to ask user for login/password.
Related
I have Google sign in button that opens new window for authorization. Can I get cookies from that frame? If the answer is yes, the next question "how?" :)
Picture below shows my cookies (localhost) and cookies that came from Google auth.
Nope, these cookies are from another domain. For security reasons, you can and never will be able to read cookies that are not from your domain.
Think about the consequences it would have if you could: people logging in on your website through some OAuth service for instance, would basically "lose" all the cookie data to your website's JavaScript context since your website happens to include some iframe/image/script from another domain. It would be able to read all cookie values and copy a login session for instance, which might be stored in it.
this is my first post,
I'm working on a project that required me to buy another domain. But i want it to use the same authentication system as my current domain and and also login the user into both sites.
I already found a great post whate it explains what needs to happen here: See the first comment
But I want to make it possible for the user to login on domain1.com (by entering credentials) and i want the credentials to be taken from domain1.com to maindomain.com and authenticate it.
Now, i know its not safe to send the users info unprotected, but i am not sure exactly how to do it any other way.
Do you have any suggestions to how i may send the login info or authenticate the users.
NOTE:
Both sites are on the Same server and one is in a subdirectory of the other (in the file tree) but they have two separate domains so i cant just tell it to POST the info to /login, instead i would have to send it to which would not work with POST.
Any and all help is appreciated!
Thanks in advance!
When the user logs in on server1, you could include something like this in the HTML:
<img src="http://server2/login/?hash=...">
(put a 1*1 transparent gif there or so)
The server should reply with a header that sets the session id.
If you are using cookie based sessions, the easiest way is to set additional copy of session cookie using iframe after successful login.
I'm writing an Apple iOS app that login to a account and fetching some balance. It use a plain html link for the login:
https://www.myaccount.com/login.jsp?username=myusername&password=mypassword
The username and password is dynamically loaded to the login link at runtime.
I've sniffed the traffic using Wireshark and I couldn't find the username or password in any of the packages being sent. I guess the SSL(?) thing of "https" have encrypted the query.
I'm I right? Is this a safe way? Any other thoughts? How should I handle the password in the app to avoid security issues? Is it cached? Do I need to encrypt it if I want the app to remember my password?
Although technically safe as Sjoerd pointed out, this is just great for social engineering. In the internet cafe: "Dammit, that's a cool article. Can you email me the URL real quick?"
You won't believe how many people fall for this kind of stuff.
Another drawback is that Browsers tend to cache URLs, so again very unsafe in situations where multiple people have access to the same machine.
A much better way is to use HTTP Basic Authentication or at least HTTP POSTing the data.
This is secure in the sense that it can not be sniffed, since the request is sent over an encrypted HTTPS channel. However, it does show up in the address bar of the browser and possibly in the log files of the server.
The safer way is to POST the username and password to the JSP page, so that they do not show up in the URL.
I'm about to encrypt my website's login form and I was wondering if the user logging in needs to land on the login form at a HTTPS URL, or whether the form data can be posted to a HTTPS url from a HTTP url and still be encrypted?
Yes, the login data is encrypted, but there is no obvious way for the user to know this. It also leaves users open to a man-in-the-middle attack because an attacker could simply change where the form posts to.
For a site that really needs security, it is highly recommend that you require https on any login page.
Yes, it will be encrypted. The URL of the page from which the form is submitted doesn't matter, only the form target URL.
One thing to note, though, is that some browsers (IE 6, at least) will warn the user when submitting a secure form from an insecure page. Why that requires a warning and what the user is supposed to do about it, I have no idea, but it can confuse people (if they bother to read the warning).
Whenever I login to one Google service, I am automatically logged in all their other websites on different domains.
What I want to know is how they are able to access the disparate cookies and sessions that belong on another domain.
I tried searching online but I couldn't find any information. I could probably pull out firebug and try to find out but I am sure someone here knows.
A Google Login works like this:
1) You login, normally at a login page that is under the Google.com/accounts domain.
1a) If you aren't on the Google.com/accounts domain, it is going to forward you there after you post the form. This can be found on sites like Blogger.
Once you arrive at the Google.com/accounts domain, they do two things
2) They set a cookie(s) that is specific to the Google.com/accounts domain, that are also only able to be sent over a secure connection. This is to verify your identity later on.
I say multiple because there are several cookies bound to the google.com/accounts domain. I believe that one of these is to make sure that all doesn't fail if secure connections aren't allowed
3) They set a cookie that spans all the domains using .google.com as their domain, because this will make the cookie available to any domain.
4) They forward you back.
5) If it is a site on a different domain, like blogger, they send along an authorization key in the URL. The page sees it, verfies it, and sets the cookie for a different domain. A technique like this can be seen using Google's Oauth.
Here is where that Secure Cookie comes in.
If you notice, whenever you go to a site after you close your browser, they forward you to the google.com/accounts path, where they reverify you under a secure connection, and then reset the subdomain-wide cookie. Then they send you back.
Furthermore, some sites like Google Adsense use the same technique as Google.com/accounts uses, by making a secure cookie on a specific path, and then using more global cookies to allow greater access.
Some of this is guessing, but given what a non-insider can see, I believe that is close to the truth.
Note: I literally spent like an entire month just browsing from Google Site to Google Site seeing how they did stuff. By upvoting this post, you are decreasing the sadness I have for having no life