So, I have this web application that shows network products for a specific network. The web server is not inside the network, so in order to show the visitor what network services he or she can order, I need to identify their computer inside the network.
So, I've been doing this with an iframe, which loads a specific in-network URL provided by my clients. This in-network URL will identify the visiting browser and then redirect it (inside the iframe) to a resource on my web service, with attached identification details.
For identification to occur, the in-network web server needs to receive a HTTP request from the visitor, but is this really the best way to handle this? Ajax cross domain is a bit of a mess as far as I'm aware, but I think iframe cross domain is equally shaky, or?
How would you solve this? The chain of events needs to be:
visitor visits my.web.com/services
visitor is sent to client.network.com/identify
Which redirects to my.web.com/identifier?id=XXYY
Now I can set a cookie for my.web.com on the user browser that their id is "XXYY" (or update member profile if logged in). Obviously this request needs to be asynchronous since the in-network web server may be slow to respond, so just a normal redirect is off the table.
Related
I have implemented authentication, based on jwt tokens in my app. But I have some trouble with logout action. When I press logout, I simply clear my local storage from access_token value.
Let's imagine, that user opened three browser tabs with my app. One of them is unprotected and there is some unsaved user input (tab1). Other tabs (tab2,tab3) have protected resources. When user press logout button on tab3, I want to redirect him on login page (because he is on protected tab). Also I want to redirect him on login page when he makes tab2 active, because it also has unprotected resources. But I do not want to redirect him from tab1 (because it is unprotected), and I do not want to renew it, because user will loose his input. How can I implement this?
TL;DR: In order to achieve this, you'll need to implement WebSockets.
A standard single page application written in angular works over HTTP, which, according to wikipedia:
HTTP functions as a request–response protocol in the client–server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.
Request-response is one of the basic methods of communication between computers. One computer sends a request, the other one sends back a response - it's just so simple (on the surface. The underlying technology handles a lot of stuff, but it's out of the scope in this answer).
But, as with any (simple) technology, it has its constraints. A request contains information about its sender. Upon receiving a request, the server handles it and sends back a response to the entity that issued the request.
Now let's consider your scenario
You have 3 opened tabs with your app and 2 problems here:
Suppose you log out on tab 3. Because you use JWT token authentication (actually any token authentication behaves similarly), the proper log out action consists of just removing the token from your local storage in the SPA project instance on the tab 3. The application state of the project in tab 1 and 2 does not change in this case. Also, logging out doesn't require any request to the server, thus no response is send that would somehow notify of the changed authentication status of the user.
Even if you'll send a request to the server to notify it about the log out action on the tab 3, the server does not know about other 2 opened tabs, because the request holds information only about the entity that issued the request, thus it will just send a response to the third tab.
Entering WebSockets
Note: Before reading on, I want to mention that I don't have practical experience with websockets, so you can take everything I write with a grain of salt.
Again, according to wikipedia (highlights are mine):
The WebSocket protocol makes more interaction between a browser and a website possible, facilitating the real-time data transfer from and to the server. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open. In this way a two-way (bi-directional) ongoing conversation can take place between a browser and the server.
WebSockets provides a full-duplex communication channel, meaning that the server doesn't only provide responses to client's request, but also initiate data transmission. This solves the second problem mentioned above leaving you the task to solve the first problem - notifying the server about the logging out of the user. Once the server knows that the user has logged out, it communicates this fact to all other clients, thus synchronizing the state of your single page application among all tabs.
Angular doesn't provide websockets support out of the box, but there are modules that give you the possibility to use them in your project. Just google it.
Hope this helps you.
We have a database with millions of domain categorizations (storing it client side is not an option) and we want to make a chrome extension to blacklist sites based on how they are categorized in the Mysql database.
The server side stuff is easy, we post the domain, and return the category.
The tricky part is blocking requests based on the categorization. Here are a few potential implementations and why they won't (quite) work.
Idea 1:
Redirect all traffic using Chrome.webRequest to mysite.com/script.php?url=www.theoriginalurl
This script checks the database's category & either redirects them to the theoriginalurl.com or denies the request, redirecting them to www.youGotBlocked...
Have the chrome extension check the http referrer header to make sure that they came from mysite.com (unless the url is mysite.com, then do nothing).
Problems:
It doesn't seem like we can set the referrer header in PHP, so we have no way of knowing that they came from mysite.com. It seems like maybe we should be passing info via a cookie, but I haven't thought of an elegant solution involving cookies.
Idea 2:
Every time Chrome.webRequest fires make an AJAX POST request to mysite.com/categorizeURL.php with the URL to get the category. Block or allow based on the server's response.
Problems:
Either we make the request asynchronous and we can't get the response in time (their is no way that we have found to delay the callback until the server responds -- more on that here). Or we make the request synchronous, and IT WORKS!!! Except for the fact that if they can't reach our server, their entire browser locks up and they essentially need to refresh the extension to be able to access the internet again.
Other ideas?
Does anyone have other ideas for creating a blacklist via a Chrome extension? I simply refuse to believe that it is not possible.
Using javascript one cannot convert an image (hosted on a different domain than the one the javascript comes from) into a canvas.
What's the security risk with that? It can't just be to avoid phishing, right?
Same origin policy stops any remote data from being accessible by a different domain. One of the main attacks this stops is being able to circumvent a user's login by waiting for them to be logged into another site, and then piggy-back your request on their authenticated session.
Whether the data loaded is an HTML snippet, an image file or anything else, it's blocked so you can't take advantage in any way (for example, by inspecting the pixel data of an image retrieved this way)
There is one tricky attack vector connected with external images: someone can post image which will be loaded from the external resource, which they control. After some time this url can be changed to return the request for the basic http authentication. So the other users will see windows requesting their login and password. Some users, especially non-experienced ones can enter the credentials of the attacking resources which will be sent to the attacker. So be careful with external resources.
I'm working on a user login system and I have come up with a solution that I wanted to run past you fine folks to make sure I wasn't about to create a giant security flaw.
Here is what we have.
You start on an HTTP page that when you click a link will open a modal window. The first link from an HTTP page when clicked will repopulate the modal with an iFrame that links to an HTTPS page. Since I can't have the HTTPS talk to the HTTP page I'm using a document.location setting on the HTTPS iframe page to make the success page HTTP. Then the HTTP page talks back to the parent window.
So:
HTTP (click) -> Opens iFrame in HTTPS -> Login over HTTPS secure on Success document.location -> HTTP success page -> window.parent.success_msg(deferred); calls to the parent window.
It's working great in all browsers so far...haven't tested IE yet, but I wanted to verify this wasn't a really terrible practice before I present it.
Thanks!
An iframe to an HTTPS URL within an HTTP page is really bad practice because it makes it hard for the user to get more detailed information (in particular security-related information) about that page. (Sure, you can probably right click and find a way to check the properties of the iframe, but even users who'd know how to do that probably wouldn't do it).
With an HTTPS iframe like this, you prevent the browser from displaying the usual security symbols: lock, green/blue bar and, more importantly, the address of the site (an attacker could just put their own link to their www.some-other-site.example instead of the indented site; www.some-other-site.example could have a legitimate certificate and the browser wouldn't give any alert message).
This practice is especially bad as an HTTPS iframe within a page served over HTTP, but it's not good either when the containing page is served over HTTPS. You can't easily verify the identity of the server serving the framed page either. (Sadly, this is (or at least was) what's recommended by 3-D Secure...)
If you want to do the authentication over HTTPS, switch the full page to HTTPS and then back, by giving a non-secure cookie. Of course, this isn't very secure (someone could intercept that security token, as popularised by FireSheep), but this is better in that at least, the user will be able to check that the page where they enter their credentials is the legitimate one. (This should be done carefully too, see this question.)
The best way is to stay over HTTPS without iframes after authentication if you can.
I have an application where I am displaying some stuff in javascript modals using jquery.
It requires the user to login for certain flows; but the user never leaves the modal.
So here is what we do currently.
During user flow if the user needs to be logged in, we hide the current div and show a login div
Keep a hidden iframe with Source link as that of our SSO server.
Once user submits the form, we submit the hidden iframe to the SSO server
If user gets logged in we proceed with the flow.
Problem is when there is error logging in. We need to get the error codes from the hidden iframe of the page; but because we don't control the content inside iframe, and it's returned by SSO server; we don't know how to read it since it's cross domain.
Any insights?
So long as there is not client side script being executed from the SSO party you do not need the iframe. The point of using an iframe for security is to prevent AJAX methods from ignoring single origin policy and circumventing SSL encryption. The answer is to remove the iframe. Request the SSO data from the server side and send it to the client from your server as the page is built.
You can't get around x-domain restrictions unless you use the jsonp protocol.
Could the user simply see the error response on page? Why do you have the iframe hidden atm?
Are you trying to silently log in the user to another system using the iframe technique?
Even though that might work on most browsers - some browsers won't pass cookies in i-frames - making this approach not a good broad audience solution.
Let me know if I can clarify.
Use JSONP to callback the function you prevented in your website, then in the iframe, you just need to invoke the javascript function: "parent.callback()".