3 ms·

> my app doesn't even rely on any servers, what do you suggest I do then? Although I agree that there is nothing wrong with client-side sanitization, does this

> my app doesn't even rely on any servers, what do you suggest I do then? Although I agree that there is nothing wrong with client-side sanitization, does this even apply to non-networked apps? Are you protecting your user from? Or perhaps by "doesn't rely on any servers" you mean "serverless", which doesn't literally mean no servers. If your app's client hits a database-as-a-service somewhere then that is a server and it very well can sanitize for you.

pjerem 5y ago
I think it's "doesn't rely on any servers that you own". You can have no back-end code but still can call external APIs hosted on servers you don't control or which can be compromised by malicious user generated content.
esrauch 5y ago
Besides the other comments there are legitimate security reasons to be worried about sanitizing in general even in zero-rpc-app cases; malicious files are an attack vector. Eg if you were making Calibre you do still want to be hardened against malicious local files from hijacking the app.
fabiospampinato 5y ago
> Although I agree that there is nothing wrong with client-side sanitization, does this even apply to non-networked apps? Are you protecting your user from? Kind of from themselves, the app can open arbitrary files, you can't have people nuke themselves by opening a random file they got from the internet, or by pasting in something they don't understand. Also a plugin may sort of escape from the boundaries put on it by XSS-ing its user by outputting some malicious stuff. > Or perhaps by "doesn't rely on any servers" you mean "serverless", which doesn't literally mean no servers. If your app's client hits a database-as-a-service somewhere then that is a server and it very well can sanitize for you. No I actually meant no servers at all, it's a 100% local Electron app.
wongarsu 5y ago
> does this even apply to non-networked apps? Are you protecting your user from? Some pages render data from GET parameters, which allows XSS by giving people a link. There's also scenarios where data from localstorage, cookies or manually copy-pasted data is an attack vector. Imagine I get you to paste my document into your text editor and that allows me to extract all your data.
runarberg 5y ago
XSS is a known vulnerability in social hacking as well as shared data. Imagine an app which allows you to paste an input which will later be rendered as HTML. An attacker can create a malicious script and persuade the victims to copy it and paste in their app. This script might include `fetch` calls to a server the attacker controls which the attacker can use to spy or install malware on the victims machine. The above example is a vulnerability in the app just the same, it just requires the attacker to consider different avenues of delivery (such as sharing the malicious script on a forum) then in traditional server connected apps.

pjerem 5y ago

I think it's "doesn't rely on any servers that you own". You can have no back-end code but still can call external APIs hosted on servers you don't control or which can be compromised by malicious user generated content.

esrauch 5y ago

Besides the other comments there are legitimate security reasons to be worried about sanitizing in general even in zero-rpc-app cases; malicious files are an attack vector. Eg if you were making Calibre you do still want to be hardened against malicious local files from hijacking the app.

fabiospampinato 5y ago

> Although I agree that there is nothing wrong with client-side sanitization, does this even apply to non-networked apps? Are you protecting your user from? Kind of from themselves, the app can open arbitrary files, you can't have people nuke themselves by opening a random file they got from the internet, or by pasting in something they don't understand. Also a plugin may sort of escape from the boundaries put on it by XSS-ing its user by outputting some malicious stuff. > Or perhaps by "doesn't rely on any servers" you mean "serverless", which doesn't literally mean no servers. If your app's client hits a database-as-a-service somewhere then that is a server and it very well can sanitize for you. No I actually meant no servers at all, it's a 100% local Electron app.

wongarsu 5y ago

> does this even apply to non-networked apps? Are you protecting your user from? Some pages render data from GET parameters, which allows XSS by giving people a link. There's also scenarios where data from localstorage, cookies or manually copy-pasted data is an attack vector. Imagine I get you to paste my document into your text editor and that allows me to extract all your data.

runarberg 5y ago

XSS is a known vulnerability in social hacking as well as shared data. Imagine an app which allows you to paste an input which will later be rendered as HTML. An attacker can create a malicious script and persuade the victims to copy it and paste in their app. This script might include `fetch` calls to a server the attacker controls which the attacker can use to spy or install malware on the victims machine. The above example is a vulnerability in the app just the same, it just requires the attacker to consider different avenues of delivery (such as sharing the malicious script on a forum) then in traditional server connected apps.