Re: mailmam, web bridge, forum, p2p (was: Diversification)

["pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>]

[-- Attachment #1: Type: text/plain, Size: 3749 bytes --]

On Thu, Oct 24, 2019 at 11:35:52AM +0200, Amirouche Boubekki wrote:
> Last time I checked the security requirements for web application that
> do not rely on JavaScript was too complicated. I preferred to forget
> about it.
> 
> See https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
> 
> The easiest path is (was?) to rely on a token sent by JavaScript.
> Meanwhile JavaScript brings other problems...


I refuse to believe Javascript is in any way necessary.  The link you
provided contains all information I previously had of tokens and more;
it is a good reference.  I did not know login CSRF before, it is very
relevant, thank you.  My current impression of best practice fits what
is described at the site you linked under “Disclosure of Token in
URL”:

Ordinary HTTP cookies are bad practice for session tokens because of
CSRF.  If you want a normal link to another page on your site but
retain the login session, you should not use cookies for that.
Session tokens must therefore be supplied in HTTP parameters (GET or
POST).  So when a logged in user makes a request, all hyperlinks in
the HTML response (except logout) need to have their HTML code
rewritten by the dynamic web server to contain the session token in
the GET parameters.  Similarly, all POST forms should contain the
session token as a parameter value.  Thus the session token is only
supplied in GET or POST requests from the same site and same session
and no CSRF is possible anymore.  Since the URL used in a GET request
will be exposed to the user, the session token should be invalidated
after verification and the response should contain a new session token
in its HTML code for hyperlinks and forms.  The downside is that URLs
are less pretty but meh…

Invalidating tokens requires the server to store for each registered
user the current session id and the timestamp until which the session
id is valid.  The same user could not be logged in simultaneously from
multiple browsers.  To enable multiple simultaneous logins by the same
user, the server could instead store more sessions than it has users,
but this might enable denial of service.  Or the server could instead
use what the site you linked describes as “Encryption based Token
Pattern” to not have this problem.  But then no token invalidation is
possible, so instead of GET requests we would need to use HTTP POST
for every hyperlink which is sometimes bad for the browser to deal
with.

Because of login CSRF the Referer header should also be verified for
all links internal to the website (external links should strip the
Referer header via redirect pages similar to what the code attached to
this mail does).

I do not know what Artanis does currently.  I will check next week.


> It seems to me the
> browser paradigm with the _JavaScript_ wanna be sandbox is the wrong
> way forward.

A sandbox does not guarantee security from hardware bugs like
Rowhammer or Spectre (but neither do multi user setups).  Also a
sandbox does not protect your computer from mining bitcoins for
someone else in a sandboxed environment.  It also permits bad,
battery-draining code.  Perhaps more importantly, JavaScript has all
kinds of privacy implications and encourages users to run nonfree
code.

> I would much prefer the modern approach where a peer
> expose an API and people build clients.
>

Many enterprises offer not APIs but non-downloadable JavaScript
service as a software substitute.

> There is proof of concept bulletin board using gnunet
> https://git.gnunet.org/gnunet-guile2.git/tree/prototypes/c3b2
>

That is interesting.  I will check.

Regards,
Florian

[-- Attachment #2: web-redirector.scm --]
[-- Type: application/vnd.lotus-screencam, Size: 3631 bytes --]