[SECURITY] POSTing without token
Closed this issue · 6 comments
Hi,
It is not safe for javascript to POST without a CSRF/bearer token, the scripts should accomodate for it. Thank you.
As far as I can tell, the only JS-initiated POST request is equipped with with a non-form Content-type header, so a CSRF is prevented via a CORS Preflight.
See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests for reference.
Hmm, what I'm trying to point out is that, POSTs can be sent and have an effect without having to load the editor UI first (to get the token).
Of course in the strict sense, the main focus of this library is to demonstrate the editor's capabilities, thus the token can be left to the developer. However, incorporating a token requires modifying the JS files, which creates a fork, not that good for developer experience if we are just looking to utliize this library.
I have coded up the authorization bearer tokens, but it is based on https://github.com/Lt-Mayonesa/wwwsqldesigner. Perhaps another approach is to allow specifying extra XHR headers when instantiating var d = new SQL.Designer();, this way, the token can be passed in and no modification of the JS files is needed.
Hope I'm making sense. Thank you.
Hmm, what I'm trying to point out is that, POSTs can be sent and have an effect without having to load the editor UI first (to get the token).
I see. The issue is not related to the JS app, but rather to the php-mysql backend implementation.
However, the currently provided backend does not perform any kind of authorization (it is literally open to anything), so I see little sense in performing a token validation in this case. Any attacker is free to POST any data to the backend - either via the app itself, or via custom HTTP requests.
I see. The issue is not related to the JS app, but rather to the php-mysql backend implementation.
Yes, I recognize that now. However, the backend alone cannot mitigate the attacks, it requires the JS to "play" its part too.
I can see a clear solution now, there is no need to validate any token, just allow specifying additional XHR headers during instantiation, this way, developers who need the authorization/security won't have to modify the JS files.
If you are open to this, I could file a PR. Thank you.
I can see a clear solution now, there is no need to validate any token, just allow specifying additional XHR headers during instantiation, this way, developers who need the authorization/security won't have to modify the JS files.
Hm, I am not that sure. There are many ways to authorize HTTP requests and I would say that picking one of those is outside of this app's scope. Others might pick a cookie-based (using the SameSite=Lax attribute) authorization instead... or a HTTP auth.
If you are open to this, I could file a PR. Thank you.
I suppose we can support adding arbitrary header values. Also, the current OZ.Request abstration is not really necessary; we should do native XHR/fetch instead.
PR done, I did not remove OZ.Request yet, IMO it would have been too big a change.