Hey i have a serious issue about storing things in the session state

[NoNeuronsNoStress]

I just found out that the all the session_state variables are stored client side, which if I understand correctly can be super dangerous for apps, that run a database (which is becoming more and more common, even with streamlit), then a malicious user could just simply overwrite the (for example) username in the session state with the use of the developer console and gain access to someone else’s account.

Or is there a security feature I’m missing ?
Need help with this ASAP

[marduk]

Hi @NoNeuronsNoStress ,

How do you access session state variables through the developer console?

My understanding was that session_state variables are not exposed there, but do let us know if otherwise. Thanks!

[NoNeuronsNoStress]

I didn’t actually do it, as a matter of fact I’m a fresh beginner with streamlit. I was just wondering if it is possible, because as I said, I just found out, that they’re stored client side. I just wanted to make sure that I am not making a huge security blunder. However if they aren’t exposed & and there is no way for the user to edit it then everything is fine.
Thanks for the quick reply

[mathcatsand]

I would love a detailed accounting of how that all works for my own curiosity since I’m not up to snuff on the nitty gritty details of security in web development.

As for what I know (just starting to make my first component), Streamlit doesn’t take on just any update to st.session_state from a change on the browser side. With the widgets for instance, there is a specific line of code in the typescript file to write to the Python backend when there is a change to a widget on the client side. I couldn’t change the allowed range of a widget from the client side for instance, even if locally I could manually edit it to have some other value that Python/React/Javascript was rejecting. My instinct is that the Python st.session_state object is safe from tampering, but it is indeed an interesting question and I’d love a security expert to explain that architecture in detail.

Here’s a little blurb in the documentation about security in Streamlit, too: Streamlit Trust and Security - Streamlit Docs

[marduk]

Hi there @snehankekre ,

A few of us are interested in understanding more about the security of Streamlit - for example, how exposed (or not exposed) are session state, the python code in our app.py file, websockets and IP addresses of sessions, etc.

Is this something the Streamlit team can share more information about? It will really help us understand how to build more secure apps (and maybe the team even has best practices to share ).

Thanks in advance!

[snehankekre]

Is this something the Streamlit team can share more information about?

Give me until later next week to get back to you on this.

[marduk]

That works, no rush! Thanks a lot

[jcarroll]

Hi folks! Streamlit developer experience PM here. Thanks for raising this and the great questions. Just to clarify answers on a couple of the questions for session_state specifically:

• Values your app stores in session_state are NOT sent to the browser or otherwise available client-side in any way. These only live on the server. Widget values (e.g. the value on your st.slider) originate in the client and thus could be accessed there, and these will also be stored in session_state, but this is incidental and unavoidable. If you found some docs or code that suggested otherwise please let us know so we can clarify them!
• There should not be vulnerabilities where an attacker can access the session_state of another app user. The session implementation is based on tornado.websocket.WebsocketHandler which is secure. If someone could access your session ID (which is not tied to any simple guessable value) they could connect to your session, but in practice this would require the attacker to have a high level of control in your browser already, similar to other cookie spoofing or cookie poisoning attacks.

For some of your other questions related to apps hosted in Community Cloud: On Community Cloud, each app has it’s own pod/containers and is isolated from all other apps on the platform. This includes your apps session_state and source code, which is maintained server side on a containerized file system dedicated for you. An attacker would need highly privileged access on the system or access to your personal login to get to these resources.

For self hosted streamlit apps, securing source code and their server in general is the users responsibility and Streamlit cant really control that environment. Let us know if this helps or if you have further questions!

[Fabio]

@jcarroll
Thanks so much for your thoughful answer.

I have a self hosted app. The user uploads sensitive data (sales records) and the app generates some charts. The app never saves the user data (nor anything else) on disk. The st cache is deleted after a few minutes.

Given what you wrote above (high difficulty in connecting to a particular session for an attacker) would it be fair - in general - to say that streamlit application organized in this way (aka that does not save data on disk) is fairly secure (assuming I did my homework, correctly secured my code and my server, eccetera?).

I have the feeling that this is indeed the case, but I struggle to have a positive confirmation.

Thanks a lot

Fabio

[jcarroll]

Hey @Fabio, I don’t see any immediate concerns about the app pattern you mentioned, especially if the app is running locally on the same machine the user is viewing it on. Unfortunately I’m not really in a position to comment generally on whether it’s secure based on my expertise or the information provided. It might be something for a new thread to see if other forum members have thoughts on how to assess this. One good framework for assessing these generally is Threat Modeling, you can find some great tools for this online if that’s helpful.

[Fabio]

Thanks @Jcarroll . I will have a look at Threat Modelling tools. But your answer is very reassuring