Comments (19)
Never mind. It's already implemented in CookieHandlerImpl
from vertx-web.
Hmm, I actually removed this in a recent commit.
Are you referring to signing cookies? (Signed cookies values are not encrypted)
from vertx-web.
Hi Tim,
Yes I am referring to encrypting cookies (via a Java Cipher for instance)
However the more I thing about it and the more I feel it's more than just encrypting cookies. IMHO it would be nice to somehow 'configure' Apex with some kind of Cipher.
Then each time something needs to be 'secured', it's done using the Cipher that's configured.
For instance, cookies could be automatically encrypted/decrypted using the configured Cipher.
Others use cases could be to encrypt/decrypt sensitive form fields maybe also some specific url parameters.
Does it make sens?
from vertx-web.
Others use cases could be to encrypt/decrypt sensitive form fields
You should just use HTTPS for that.
from vertx-web.
Sorry for the late answer, it was prety hectic lately.
The main issue with 'regular' cookies is that they can be modified client-side. If you use HTTPS it prevents people from eyedropping the data (including cookies) transmitted back and forth between the client and the server. IMHO HTTPS is a must have in almost any web applications.
However, HTTPS does not prevent a user from modifying cookie data client-side.
Encrypting cookies (AES 256, CBC for instance) prevents users from tampering data stored inside cookies. In some case, it's perfectly OK to use plain-text cookies. In others cases, we really want to make sure that cookie data can't be modified in any way.
IMHO, Vertx should support this use case and let developers decide whether they need to encrypt cookies or not.
From a technical stanpoint, it's a no brainer to support cookie encryption. The 'challenge' though is to make sure that people can use whatever encryption technology they want (AES, Blowfich, HMAc + AES, etc...)
I propose we add the interface CookieCodec. We provide a couple of must-have implementations of that interface.
We also need to update the CookieHandler as follow:
'''
@VertxGen
public interface CookieHandler extends Handler {
/**
-
Create a cookie handler
* -
@return the cookie handler
*/
static CookieHandler create() {
return new CookieHandlerImpl();
}/**
-
Create a cookie handler using the specified CookieCodec
* -
@return the cookie handler
*/
static CookieHandler create(CookieCodec codec) {
return new CookieHandlerImpl(codec);
}
}
'''
If there is an interest from others people I can work on this and submit a PR quickly.
Let me know.
from vertx-web.
+1, I'm in favor.
from vertx-web.
I think this would be a nice feature, although usually this requirement can be designed away by never storing important information in a cookie and just using an id to lookup the session on the server side.
E.g. the Vert.x session cookies are cryptographically secure random GUIDs so it doesn't matter if they are tampered with.
from vertx-web.
The issue with looking up the info on server is, 1) you take up server
memory, 2) It can make scaling out to other servers difficult.
I think it would be nice to offer support for both server as well as client
sessions, to let people choose whichever one works for them.
On Mon, Mar 23, 2015 at 4:05 PM, Tim Fox [email protected] wrote:
I think this would be a nice feature, although usually this requirement
can be designed away by never storing important information in a cookie and
just using an id to lookup the session on the server side.E.g. the Vert.x session cookies are cryptographically secure random GUIDs
so it doesn't matter if they are tampered with.—
Reply to this email directly or view it on GitHub
#28 (comment).
from vertx-web.
A little security improvement could be to set the HttpOnly flag in order to prevent cookie stealing by an XSS attack (https://www.owasp.org/index.php/HttpOnly).
from vertx-web.
as @leolux says, HttpOnly should be default options for session cookies to help mitigate attacks using the cookie and scripting. In additional the other parts of this issue such as encryption are valuable.
from vertx-web.
Instead of encrypted cookies we can sign cookies which is common on other frameworks such as node, Django, php. That would be easier to implement since it is just a endHandler that when active will sign the cookie and a validator when reading the cookie.
That and using httpsOnly would already give you a high level of trust.
The problem of encrypting a cookie is that clients will not be able to read the cookie anymore unless there is a decrypter at the client side. if you have a decrypted in javascript if will probably make it way to easy to break the security since the scripts would be available freely.
from vertx-web.
What is the state of this feature ? Can we sign or encrypt cookies ?
Now, using an encrypted (or just signed) cookies to store the session is the default of most web frameworks... The main advantage of storing session in a cookie is because it's more easier to scale (and it doesn't make the app less secure, I would even say it makes it more secure because sessions are not stored in a centralized place).
Using httpOnly should be the default too. A well coded web application rarely need to access cookie in JavaScript (and if it's needed it can be enable because it's just an option). Also we should have ability to mark the cookie as "secure" when used in conjonction with https.
from vertx-web.
@serphacker it is not implemented since the discussion was still open and no consensus was achieved. Also if we're at it, it could be nice to revisit the session code and see if we could implement a cookie based session storage since at the moment you can only store your sessions (backend wise) using a local or shared map.
from vertx-web.
Yes it is more about providing a cookie based session system than a "whole cookie encryption". If the session value is stored client side (in a cookie) it should be :
- signed, mandatory to avoid session tempering from client, ie setting admin=true in the cookie.
- encrypted, optionally, but will improve security by hiding session variables
- timestamped, here it's not just about setting a cookie expiration time. If your session contains userid=1 and its cookie expired, it will be deleted from your browser. But, nothing prevent an attacker to resend the same value (in a fresh cookie) 10 years later, and it would still be valid, that's why we may need a timestamp in the session itself.
- httpOnly
- secure (optionally)
I did take a look at SessionStore, SessionHandler etc. and it would need a bit of refactoring to support CookieSession.
from vertx-web.
@serphacker are you volunteering for a PR for this then?
from vertx-web.
I can't now, I don't know yet if I switch from ninjaframework to vertx-web for our next project. So don't count on me now.
from vertx-web.
@serphacker ok no problem, i'll mark it as "help wanted" since we are currently hands full with other issues and soon adding support for HTTP2 so this is currently not critical.
from vertx-web.
@serphacker @purplefox @pmlopes I'm actually implementing a similar solution on a private project..
I might consider writing it as a PR to the vertx-web repo..
Can you clarify what is the needed spec?
from vertx-web.
Closing as there's no activity for more than 1 year. Cookies can be updated or modified easily with a custom handler.
from vertx-web.
Related Issues (20)
- oauth2 should not redirect (HTTP 302) XHR requests HOT 2
- HttpContext.fail() does not release the connection when invoked in SEND_REQUEST phase
- WebClient: NPE on misformatted Date or Expires header HOT 1
- absoluteURI is null when host header is missing HOT 2
- Issue with POST request hanging indefinitely in Vert.x Web HOT 3
- CSRF validation fails because CSRFHandler updates the session AFTER the session is already flushed HOT 1
- SockJS Event Bus Bridge does not keep web sessions alive for clustered session managers
- When upgrade vertx4, the path cannot support colon, and vertx 3 is ok HOT 1
- Use the new `OAuth2AuthorizationURL` in `OAuth2AuthHandler.extraParams`
- Reduce heavy atomic operations on RoutingContextImplBase HOT 1
- Rx Version of OAuth2AuthHandler Handler fails to add scopes HOT 2
- Vertx web randomly returns 404 error for certain POST requests even though for other similar requests it returns 200 HOT 2
- ChainAuthHandlerImpl#postAuthentication throws NPE HOT 1
- BodyHandler should not be added before the ProxyHandler HOT 2
- after RoutingContext.reroute(), TimeoutHandler still occured HOT 1
- Request to add localstorage-functonalities HOT 1
- GraphQL: Combination of request batching and Automatic Persisted Queries fails HOT 1
- New web client expectation, result type differ from error type HOT 5
- Exeptionhandler not working correctly HOT 5
- HTTP 1.0 request causes "Unhandled exception in router" HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vertx-web.