I have a demo to make in which first a secure session is created with domain (let's call it paranoids.com), and then a bunch of locally read html+javascript (my demo) want to use that secure session. We are using google-chrome, started with --disable-web-security and --allow-file-access-from-files, on a linux/openSuse platform.
Why do I need to do that? I need to scrape some pages from that domain and re-render them with an alternative renderer. We have absolutely no say with that other domain owner.
What's the best possible approach for this, without asking my poor breadgiver to go through technical hoops? Can my script access the JSESSIONID of the domain paranoids.com when run with some command line arguments? Or, is it just not possible, and must the user copy/paste the cookie manually?
Thanks for any ideas that help realize that goal.
Related
Recently I worked on a project, which is a real time web application.
I use socket.io as the data server, and let's suppose that its domain is www.a.com. On the other hand, I use express as the http server, and its domain is www.b.com.
Now the problem comes, if I want to synchronize the session between two server(that means, if user login www.a.com by socket.io, he/she is logged in when he/she visits www.b.com), how can I do that?
Thanks in advance :)
ps: please forgive my poor English...
== Update ==
I have tried one solution: use the magic of postMessage to communicate between different tabs.
When a user login in www.a.com, I create a iframe, whose src refers to www.b.com. And then I can pass login data from www.a.com to www.b.com, and trigger something to login in www.b.com.
But I think it is not a best way to solve the problem, is it safe? or generate other problem? And I wonder if there are other solutions.
By their nature, cookies (which store session id) can't be read from different domains. I know of a mod for Apache that could encrypt login data from one domain and place it in a GET request (address bar) so the user wouldn't then have to log into a second domain. Sorry, I can't recall what it was called, but you could do something similar, all you'd need is require('crypto') I believe.
EDIT: Why do you want the sockets & web server to run on different domains? If they ran on the same domain, I believe there is a module to allow sockets.io to get the session data. I didn't use it myself, just read about it.
I'm in the process of making a portal website and I wanted to include an iframe which would route people to an intranet. Is there any downsides to this as far as security is concerned?
I think that maybe there's a misunderstanding on your side regarding the function of IFrames: An <iframe> will not route anything. It just tells the user's browser which URL to fetch and show inside it. This means that
People need access to the intranet to actually load the contents of the <iframe>, which might not be what you expected.
It's not a security risk per se.
It is no more or less secure than giving those people direct web access to that intranet.
If you really want to know whether something is "secure" or not, you need to specify the types of threat that you need to protect against, what your tolerance is for breaks in that security, and what additional mechanisms that you have taken to secure your site (for example password authentication, NTLM, SSL, etc).
I'm working on a little node.js-project, and while googling alot, I kinda got a bit confused, but maybe some of you are able to point me towards the road again.
Several websites are generated by DocPad (excellent piece of software), and hosted on different domains.
All these websites shall now get a "login module" (which is also written in Node.js, using passport). Visually, it will look similar to the excellent login-slider from Web-Kreation (Here a demo). My plan was to use nginx and route all the /login-requests to the login-app, which is working fine.
The problem is rather related to the multiple domains, and the clientside implementation of it all. All logins use the same database.
Can I somehow use both together, and create the session-cookies from the Login-Module (which could use the same domain all the time)?
I'm answering my own question for reference, in case someone else comes across the same problem.
In the end, I solved my problem by having a bit of a different setup. Instead of a module, using the dns of each page, I use a central login-application for all sites. The sites itself do not require to access any personal information, so that's not a problem.
DocPad is still being used to generate the different websites (works excellent - I know I say this very often, but if there's a brilliant piece of software out, there's no reason to not mention it once in a while) statically, and all static content is delivered to the user using a CDN.
The login-system is a node.js-application using Redis as the only database. It is integrated via a simple iframe on all pages rendered by DocPad on login.example.com.
After successful login in 'login-app' you can create encrypted string with info about current user. You can pass this string back in get/post parameter with redirect to necessary domain. Encription key is known only to the 'login-app' and your websites. You can trust this encrypted data. It is necessary to make sure that every time the key is different for the same user. For example you can add the information about the time of login or random. After decrypting the data you can set authorization cookie for a particular domain.
new to play,
I noticed in tutorial and online documentation that play's secure model
uses Security.connected() method to get current connected user.
my question is, how does it work ? how can play know who sent the last request ?
does it use a cookie ?
if so, copying this cookie would allow me to use different computers for viewing page ?
Yes, Play use cookie to get the user information. The cookie itself is encrypted. Not sure if copy it to another computer allow you to view the page. But I think this is not a security leak. Say, if you have a secure word document, and you copy it to another computer, it will allow the user on that computer to view your doc.
I want to log onto Stack Overflow using OpenID, but I thought I'd set up my own OpenID provider, just because it's harder :) How do you do this in Ubuntu?
Edit: Replacing 'server' with the correct term OpenID provider (Identity provider would also be correct according to wikipedia).
You might also look into setting up your own site as a delegate for another OpenID provider. That way, you can use your own custom URL, but not worry about security and maintenance as mentioned already. However, it's not very difficult, so it may not meet your criteria :)
As an example, you would add this snippet of HTML to the page at your desired OpenID URL if you are using ClaimID as the OpenID provider:
<link rel="openid.server" href="http://openid.claimid.com/server" />
<link rel="openid.delegate" href="http://openid.claimid.com/USERNAME" />
So when OpenID clients access your URL, they "redirect" themselves to the actual provider.
I've actually done this (set up my own server using phpMyID). It's very easy and works quite well. One thing that annoys me to no end is the use of HTML redirects instead of HTTP. I changed that manually, based on some information gotten in the phpMyID forum.
However, I have switched to myOpenId in the meantime. Rolling an own provider is fun and games but it just isn't secure! There are two issues:
More generally, you have to act on faith. phpMyID is great but it's developed in someone's spare time. There could be many undetected security holes in it – and there have been some, in the past. While this of course applies to all security-related software, I believe the problem is potentially more severe with software developed in spare time, especially since the code is far from perfect in my humble opinion.
Secondly, OpenID is highly susceptible to screen scraping and mock interfaces. It's just too easy for an attacker to emulate the phpMyID interface to obtain your credentials for another site. myOpenId offers two very important solutions to the problem.
The first is its use of a cookie-stored picture that is embedded in the login page. If anyone screen-scapes the myOpenId login page, this picture will be missing and the fake can easily be identified.
Secondly, myOpenId supports sign-in using strongly signed certificates that can be installed in the web browser.
I still have phpMyID set up as an alternative provider using Yadis but I wouldn't use it as a login on sites that I don't trust.
In any case, read Sam Ruby's tutorial!
I personnally used phpMyID just for StackOverflow. It's a simple two-files PHP script to put somewhere on a subdomain. Of course, it's not as easy as installing a .deb, but since OpenID relies completely on HTTP, I'm not sure it's advisable to install a self-contained server...
Take a look over at the Run your own identity server page. Community-ID looks to be the most promising so far.
I totally understand where you're coming from with this question. I already had a OpenID at www.myopenid.com but it feels a bit weird relying on a 3rd party for such an important login (a.k.a my permanent "home" on the internet).
Luckily, It is easy to move to using your own server as a openID server - in fact, it can be done with just two files with phpMyID.
Download "phpMyID-0.9.zip" from http://siege.org/projects/phpMyID/
Move it to your server and unzip it to view the README file which explains everything.
The zip has two files: MyID.config.php, MyID.php. I created a directory called <mydocumentroot>/OpenID and renamed MyID.config.php to index.php. This means my OpenID URL will be very cool: http://<mywebsite>/OpenID
Decide on a username and password and then create a hash of them using: echo -n '<myUserNam>:phpMyID:<myPassword>' | openssl md5
Open index.php in a text editor and add the username and password hash in the placeholder. Save it.
Test by browsing to http://<mywebsite>/OpenID/
Test ID is working using: http://www.openidenabled.com/resources/openid-test/checkup/
Rerefence info: http://www.wynia.org/wordpress/2007/01/15/setting-up-an-openid-with-php/ , http://siege.org/projects/phpMyID/ , https://blog.stackoverflow.com/2009/01/using-your-own-url-as-your-openid/
The above answers all seem to contains dead links.
This seems be a possible solution which is still working:
https://simpleid.org/