4 ms·

SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a s

by water9 3y ago

SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a surface that is small.

zmxz 3y ago
SSR has nothing to do with roles being sent and what a user can see. It's as related as Jupiter is to a brick.
- water9 3y ago
  It has to do with the size of the attack surface. in order for things to be client side driven gui elements need to be loaded for different role types. Those elements are often exposed If not directly then by showing which APIs are used to Authorize access to admin areas. That’s the whole point of rendering on the client. To load some Little div you might have an API call that when access by different role types will respond differently. With Server side rendering you never see the different API points for each role type As they get their own.
  - zmxz 3y ago
    Why would the elements HAVE to be loaded for different roles? You're talking as if every single client-side app approaches authorization and authentication the same way and that's just not true. There's no attack surface here at all, the only issue with most client-side apps and interaction with server comes from CORS and devs copypasting solutions from SO to get rid of the warning, thus creating the attack surface. The choices related to displaying appropriate elements based on current user's role that's tied to entire logic of the app has literally zero to do with security.
    - water9 3y ago
      Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider.. that’s why you have JWTs and stuff like that. Architecturally when you have a session management system, where state is able to be maintained per user usually up by the same thread on the same physical server. that’s going to be more secure than a horizontally structured infinitely scalable system. But there’s always trade-off between security and usability/performance
      - zmxz 3y ago
        > Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider No, the whole point of client-side rendering is to apply parasitic computing and offload the server by having the client perform work it can thus saving the bandwith and compute power. Next benefit is application that's "snappy" and works well, which is what almost never happens sadly. > that’s why you have JWTs and stuff like that. No, you don't have JWT and "stuff like that" because of this. JWT is for offloading databases so you don't have to talk to a DB on every request since you can verify the token via signature check and thus implement distributed services that don't have to talk to central authority to authorize a request. > where state is able to be maintained per user usually up by the same thread on the same physical server And now you're trying to sound smart by adding servers and "threads". I've a feeling you're pulling my leg right now so I'll excuse myself since you started spouting absolute nonsense.
        water9 3y ago
        What are you talking about? It’s well-known that Apache has a philosophy that every connection should be serviced by its own thread, whereas NGINX is an event driven architecture which means you have a thread-pool: think of it this way it’s like having the same dedicated waiter at a restaurant versus having the first available waiter come service your table or refill your drink, even if that waiter is different each time. Concerning JWT, I think we were talking past each other as I was referring to a session-less Authentication scheme, which is more or less what you describe. Finally, there’s no reason why the server can’t render JavaScript as well other parts of the page. In effect, if the server wanted to, it could render of a reactive version or an angular version depending on a variable. Can the client do that?
BackBlast 3y ago
SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser which will then parse and execute code based on that rendering. You have to be sure your data going into the database doesn't have XSS escapes or your rendering of untrustworthy data doesn't have such XSS escapes. Which is why you shouldn't roll your own SSR unless you are fully aware of this. SPA doesn't have this problem as it will generally insert DB data into the DOM as text, no possibility of escape or execution by potentially malicious database entries. Not that you can't have issues in an SPA, but you have to do work to bring them about.
- lolinder 3y ago
  This isn't a difference between SSR and SPA, it's a difference between using a modern framework and rolling your own. If I get a user-provided string from the server as a JSON property and set it via `.innerHTML =`, I have an XSS vulnerability. If I use React's JSX string interpolation, I don't. If I get a user-provided string from a database and inject it with a PHP `<?= ?>` tag directly, I have an XSS vulnerability. If I use Laravel with Blade templates [0], I don't. You're not saved from XSS by virtue of using JavaScript to render your code, you're saved from XSS by using a framework that escapes everything by default. Whether that framework builds the escaped HTML on the client or the server is immaterial. [0] https://laravel.com/docs/10.x/blade#displaying-data https://laravel.com/docs/10.x/blade#displaying-data
  - BackBlast 3y ago
    You have to explicitly use .innerHTML. As I said, "do work", not that it is impossible. No SPA frameworks do this by default. The default is $DOMElement.textContent = value, which has no escape potential. Everything rendered by the server has this potential as it must be deserialized by the browser.
    - lolinder 3y ago
      > No SPA frameworks do this by default. No, but I've definitely seen bespoke, hand-rolled frontend code do it. You can't select SPA frameworks as representative of frontend rendering but look only at hand-rolled PHP from 2002 for backend rendering. No major SSR framework is XSS-vulnerable by default. Whether you're using Rails, Laravel, Spring, ASP.NET, Phoenix, or whatever, every template engine escapes your strings unless you opt-in with something like Rails's `html_safe`, and they have for over a decade. Unless you've built your own SSR framework by hand with raw string interpolation, the "easy" way to do things is also the right way, just as it is in React.

by water9 3y ago

SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a surface that is small.

zmxz 3y ago

SSR has nothing to do with roles being sent and what a user can see. It's as related as Jupiter is to a brick.

water9 3y ago
It has to do with the size of the attack surface. in order for things to be client side driven gui elements need to be loaded for different role types. Those elements are often exposed If not directly then by showing which APIs are used to Authorize access to admin areas. That’s the whole point of rendering on the client. To load some Little div you might have an API call that when access by different role types will respond differently. With Server side rendering you never see the different API points for each role type As they get their own.
- zmxz 3y ago
  Why would the elements HAVE to be loaded for different roles? You're talking as if every single client-side app approaches authorization and authentication the same way and that's just not true. There's no attack surface here at all, the only issue with most client-side apps and interaction with server comes from CORS and devs copypasting solutions from SO to get rid of the warning, thus creating the attack surface. The choices related to displaying appropriate elements based on current user's role that's tied to entire logic of the app has literally zero to do with security.
  - water9 3y ago
    Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider.. that’s why you have JWTs and stuff like that. Architecturally when you have a session management system, where state is able to be maintained per user usually up by the same thread on the same physical server. that’s going to be more secure than a horizontally structured infinitely scalable system. But there’s always trade-off between security and usability/performance
    - zmxz 3y ago
      > Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider No, the whole point of client-side rendering is to apply parasitic computing and offload the server by having the client perform work it can thus saving the bandwith and compute power. Next benefit is application that's "snappy" and works well, which is what almost never happens sadly. > that’s why you have JWTs and stuff like that. No, you don't have JWT and "stuff like that" because of this. JWT is for offloading databases so you don't have to talk to a DB on every request since you can verify the token via signature check and thus implement distributed services that don't have to talk to central authority to authorize a request. > where state is able to be maintained per user usually up by the same thread on the same physical server And now you're trying to sound smart by adding servers and "threads". I've a feeling you're pulling my leg right now so I'll excuse myself since you started spouting absolute nonsense.
      - water9 3y ago
        What are you talking about? It’s well-known that Apache has a philosophy that every connection should be serviced by its own thread, whereas NGINX is an event driven architecture which means you have a thread-pool: think of it this way it’s like having the same dedicated waiter at a restaurant versus having the first available waiter come service your table or refill your drink, even if that waiter is different each time. Concerning JWT, I think we were talking past each other as I was referring to a session-less Authentication scheme, which is more or less what you describe. Finally, there’s no reason why the server can’t render JavaScript as well other parts of the page. In effect, if the server wanted to, it could render of a reactive version or an angular version depending on a variable. Can the client do that?

BackBlast 3y ago

SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser which will then parse and execute code based on that rendering. You have to be sure your data going into the database doesn't have XSS escapes or your rendering of untrustworthy data doesn't have such XSS escapes. Which is why you shouldn't roll your own SSR unless you are fully aware of this. SPA doesn't have this problem as it will generally insert DB data into the DOM as text, no possibility of escape or execution by potentially malicious database entries. Not that you can't have issues in an SPA, but you have to do work to bring them about.

lolinder 3y ago
This isn't a difference between SSR and SPA, it's a difference between using a modern framework and rolling your own. If I get a user-provided string from the server as a JSON property and set it via `.innerHTML =`, I have an XSS vulnerability. If I use React's JSX string interpolation, I don't. If I get a user-provided string from a database and inject it with a PHP `<?= ?>` tag directly, I have an XSS vulnerability. If I use Laravel with Blade templates [0], I don't. You're not saved from XSS by virtue of using JavaScript to render your code, you're saved from XSS by using a framework that escapes everything by default. Whether that framework builds the escaped HTML on the client or the server is immaterial. [0] https://laravel.com/docs/10.x/blade#displaying-data https://laravel.com/docs/10.x/blade#displaying-data
- BackBlast 3y ago
  You have to explicitly use .innerHTML. As I said, "do work", not that it is impossible. No SPA frameworks do this by default. The default is $DOMElement.textContent = value, which has no escape potential. Everything rendered by the server has this potential as it must be deserialized by the browser.
  - lolinder 3y ago
    > No SPA frameworks do this by default. No, but I've definitely seen bespoke, hand-rolled frontend code do it. You can't select SPA frameworks as representative of frontend rendering but look only at hand-rolled PHP from 2002 for backend rendering. No major SSR framework is XSS-vulnerable by default. Whether you're using Rails, Laravel, Spring, ASP.NET, Phoenix, or whatever, every template engine escapes your strings unless you opt-in with something like Rails's `html_safe`, and they have for over a decade. Unless you've built your own SSR framework by hand with raw string interpolation, the "easy" way to do things is also the right way, just as it is in React.