Consider a web server (HTTP) that fetches some data from somewhere and displays it as convenient HTML to its users.
Also consider that the fetching process involves confidential data like usernames/passwords of its users. One example is our HTTP server contacting SMTP servers of popular email services such as gmail, yahoo, etc.
It would be smart to use TLS, as we don't want confidential data being exposed to men-in-the-middle.
So, the current model is:
[end user] <-TLS-> [our HTTP server] <-TLS-> [other SMTP server]
The problem here is that our HTTP server has cleartext access to the confidential data from its end users.
What would be really nice is for the end user's browser to initiate a connection to the other SMTP server directly.
The two problems are:
the browser only understands HTTP at the networking level
XMLHttpRequest normally does not allow cross-domain requests
One idea that I came up with is for the end user's browser to act like it's going to create a TLS connection to the other SMTP server, but instead of inttiating a connection to the other SMTP server, to simply send Byte-for-Byte all the data that it would send to our HTTP server instead (perhaps through WebSockets), and the HTTP server will just "proxy" the TLS encrypted data to and from the other SMTP server.
I already would know what to do on the server side, but I want to know the best practice for implementing this on the client side.
Also, does this not seem like it would be a relatively popular feature in the realm of security? The example I gave was for SMTP but it equally applies for any other protocol that can use TLS. I feel like there would be standard JavaScript methods or such.
Related
We have a Google http(S) LB in front of a Google Compute VM, and we are routing a subdomain to the backend which exposes only a wss endpoint. I couldn't find any example for javascript code how to use Authentication with Google IAP and OIDC Tokens.
Does Google IAP support query parameters for the authentication ?
I found this entry:
Bearer authentication for websocket
Thanks for any advice
There is no method in the JavaScript WebSockets API to customize WebSocket headers from JavaScript, you’re limited to the “implicit” auth (i.e. Basic or cookies) that are sent from the browser. Further, it’s common to have the server that handles WebSockets be completely separate from the one handling “normal” HTTP requests. This can make shared authorization headers difficult or impossible. One way to attain this is using a “ticket”-based authentication system.
When the client-side code decides to open a WebSocket, it contacts
the HTTP server to obtain an authorization “ticket”.
The server generates the ticket. It typically contains some sort of
user/account ID, the IP of the client requesting the ticket, a
timestamp, and any other sort of internal record keeping you might
need.
The server stores this ticket (i.e. in a database or cache), and
returns it to the client.
The client opens the WebSocket connection, and sends along this
“ticket” as part of an initial handshake.
The server can then compare this ticket, check source IPs, verify
that the ticket hasn’t been re-used and hasn’t expired, and do any
other sort of permission checking. If all goes well, the WebSocket
connection is now verified.
Refer to the link for websocket security and related stack posts HTTP headers in websockets client API and Websocket authentication.
I know there are no standard JS WebSocket APIs for the same. My main aim is to send the info like resourceId, routingInfo, auth-token, protocol etc. from JS web-socketclient to the server.
I could think of below few approaches. Kindly share the thoughts if my approach is fine or is there any other better approach:
Can we use cookies for sending the custom headers from client and retrieve them in server side?
Can we use web-storage API for storing them in the browser and retrieve them on server side?
PS: I am using a Java based server
Assuming you're talking about a webSocket connection from a browser, here are your traditional choices for sending additional "header-like" information.
You can encode them as a query parameters on the initial URL which might be fine for everything except auth-token.
If the origin you are connecting the webSocket connection is the same as the origin of your web page, then you can put the parameters into cookies and those cookies will be sent with the original webSocket connection request where the server can retrieve them upon the connection request.
You can make a "conditional" webSocket connection to the server and then send credentials in subsequent webSocket messages. You'd have to implement safety for that on your server so that the "conditionally" connected webSocket was not allowed to do anything else except authenticate itself and probably timeout the connection if appropriate credentials do not arrive shortly.
As it sounds like you may already know, the browser interface to webSockets does not allow custom headers on the initial HTTP request that starts the webSocket connection. Those custom headers are possible from some other kind of client - it's just that the browser interface to a webSocket connection does not have that feature.
Can we use web-storage API for storing them in the browser and retrieve them?
The Javascript in your web page can use the web-storage API to store data in the browser and that data can be retrieved later from another script in a page from the same origin. That data is not available to the server, it is only available within the client.
If I log a user in via a secure HTTPS AJAX POST, does this mean the body of the HTTP POST is encrypted and therefore secure?
It depends on what you want to protect against (what threats should be mitigated).
HTTPS is a secure channel between the client (browser in this case) and the server. This means anybody with sufficient privileges on the client, and also on the server can read the data, because those are the ends of the imaginary pipe that HTTPS is. Practically any admin on the client or on the server can read the transmitted data, but a man-in-the-middle attacker (somebody on the network inbetween) cannot, HTTPS is secure against that (and only that, albeit it's not just confidentiality that HTTPS provides, but that's a separate topic).
The more important question is, how will you put the username and password into the body of an ajax request? That would mean you had to store such username and password somewhere on the client, where it is most probably not very secure. For instance any single successful XSS attack can reveal such credentials to an attacker. That would probably be my primary concern in this case.
An HTML form has been filled out and now it's time to send the data via email. The server hosting the HTML is not running any server side scripting language like PHP, ASP, CGI etc. The owners don't want the email coming from outside of their walls, so no SMTP.js.
A fellow at work provided the SMPT server and port 25 and says to use Websockets, or to use Flash. I'm under the impression that port 25 is blocked by browsers, and they will need some kind of server side support to send an email. Alternatively, to use a mailto link to utilize their computer's email client.
Maybe I'm not up on current technologies. Are websocket the way to go? Don't they need a websocket server running to answer those calls?
Is there another solution to sending email from Javascript directly to an SMTP server?
Thanks to some highlighting, looks like I had SMTP.js confused with smtpjs, which just uses someone else's server to send mail. SMTPJS needs node.js, which they aren't running. Darn.
You are right about websockets. Its not a "tcp socket" you can use for smtp communication.
And if you could, you would have to make sure the clients can reach your smtp server. Many isp blocks port 25 to other servers then their own to reduce spam from their network. Forget about flash. Its dead and will give you the same problem with blocket smtp port.
I would solve this by using a web server with support for server side code. If you cannot move your webpage to that server, you can use cross site scripting to communicate with a server with support for server side code.
I have an ASP.NET website that heavily uses JSON services. The basic structure is: jQuery Plugins -> JSON Service -> Server-Side BAL.
But, this solution is obviously not secure, since a malicious user can run a tool such as Fiddler and capture JSON calls on their machine, then replay these JSON calls changing parameters, etc.
If I were to put the web services folder under SSL, what protections would it give me? I tried putting the entire site under SSL, but still running Fiddler I can see clear-text messages going to HTTPS protocol, and I can replay those messages from Fiddler with the same or changed parameters.
I obviously have little knowledge about SSL and need some help. Does it sound like my SSL is not setup correctly, or being able to see SSL traffic via Fiddler is expected? If the latter, what protection does SSL provide in my scenario?
Thank you.
SSL only encrypts the transport. Meaning a third party cannot eavesdrop on the data exchange between the client and your server. It does not add any security features to the server or service itself.
What you need is a proper authentication, permission and validation system. Every request needs to be checked for its validity. Be prepared to receive any sort of request with any sort of parameters, be that because the user fiddled with the parameters, because of a bug in your code or whatever. If a request is invalid, meaning if a particular user is not allowed to do a certain thing, reject the request.
This is not some addon technology you can implement, it's a core design consideration of your service.
If Bob implements SSL on his website, then when Alice uses the site, then Mallory will not be able to intercept the data or alter it in-flight. SSL keeps messages between Alice's browser and Bob's server secret. It does not keep messages between Alice and Alice's browser secret.
There are two approaches you can take to protect yourself from malicious data.
Escape (or the equivalent) everything before inserting it into a different format. e.g. use prepared statements on SQL, build JSON with a JSON serializer and not string mashing, etc.
Authenticate users and only accept data from those that you trust