Hi,
I know how to store a piece of info into session and make it available in Liveview socket. How would I do the reverse? That is, to update that same piece of info into session from within an established Liveview connection?
Thanks a lot!
Hey!
You cannot update the session from within LiveView.
This post https://thepugautomatic.com/2020/05/persistent-session-data-in-phoenix-liveview/ suggests an alternative approach.
1 Like
thanks a lot, that is what i look for!
This approach leave the doors opens to anyone wanting to mess with a session, they just need to fire-up the same request from cURL and the session will be blindly modified or am I missing something on the suggested approach?
yes, the possibility is there, but there is csrf token to protect. Also, my use case is very limited, i allow only to change 1 key with a set of limited values that i strictly control at the backend…
that said, this is not a perfect solution, but i does serve my case.
Are you enforcing it in each request to set values in the session? I ask because the code in the article is not clear.
Anyway I really don’t recommend this typo of approach to open the server session to be manipulated from the outside, because you may know on behalf of who the backend is being accessed but you don’t know what is accessing it.
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
You can think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
So I recommend that each time you are developing a backend that you always keep in mind the the difference between the who and the what, because in the end this will help you to build a more secure backend.
You can say that the csrf_token will tell you the what, but keep in mind that this token is a very weak guarantee for that, because is very easily extracted from the page source.
It’s all about trade-offs, but in light of what I said you may want to rethink or not your approach.
Happy coding 
Thanks a lot for the advice and the great link. I will keep that in mind.
Yes, the csrf token is enforced in each request to alter the session key. For my case, I actually really don’t care about the difference between who and what. So, that is ok, except that the csrf token can be extracted and used by a bot to attack my server! For that case I employ a request/ip throttling method at server side. I hope that is enough, or do I miss some other obvious attack vectors?
1 Like
So you indeed care about who vs what is accessing your backend, and that a positive thing
Oh for sure you missed, but don’t worry that you are not alone, because even the so called enterprise grade solutions miss them 
So in reply to you question, and as I always recommend in my StackOverflow answers:
DO YOU WANT TO GO THE EXTRA MILE?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For Web Apps
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a “best practice” penetration testing framework which users can implement in their own organizations and a “low level” penetration testing guide that describes techniques for testing most common web application and web service security issues.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
1 Like
