Difference between revisions of "Security notes / website security notes"

From Helpful
Jump to: navigation, search
m (CORS)
m (CORS)
Line 75: Line 75:
 
{{stub}}
 
{{stub}}
  
 +
The idea is roughly that initial page loads can do what it wants, but anything that is external and/or executed later needs to be thought about.
  
Things where execution might in some way be involved (e.g. embedded fonts, WebGL textures, fetching anything via XHR / Fetch, image loads via drawImage) are restricted via the [https://en.wikipedia.org/wiki/Same-origin_policy '''same-origin policy'''], a basic security model that says that these resources ''must'' come from the same origin.
+
It's both about what you are fetching, and when.
  
Origin here meaning protocol+host+port (because that implies the same web server).
+
As such, ''embedding'' images, stylesheets, scripts, iframes, audio and video is generally not restricted.
  
{{comment|(For context, ''embedding'' images, stylesheets, scripts, iframes, audio and video is generally not restricted)}}
+
But things where execution might in some way be involved (e.g. fetching anything via XHR / Fetch, image loads via drawImage embedded fonts, WebGL textures) are restricted via the [https://en.wikipedia.org/wiki/Same-origin_policy '''same-origin policy''' (SOP)], a basic security model that says that these resources ''must'' come from the same origin.
  
 +
Origin here meaning protocol+host+port (because that implies the same web server or at least reverse proxy).
  
  
Line 100: Line 102:
 
'''Securitywise'''
 
'''Securitywise'''
  
* is itself '''not XSS / CSRF protection'''
+
* The idea behind SOP is that you have to do some work to mix data between different domains, in certain directions
: because any server can say "yes okay fine", so e.g.
+
: This helps protect against ''some'' cases of [[XSS]], but not others
 +
:: it e.g. often doesn't help if code was injected already
 +
:: it doesn't prevent giving you executable things - because it's the ''server'', not the page, that says it's okay to execute it.
 +
 
 +
* It's not protection against injected "load executable things from here" style XSS, because ''that injection'' is already the bad thing, and any server can say "yes okay fine", so e.g.
 
:: if someone can inject code that does XHR/fetch, then CORS ''cannot'' save you
 
:: if someone can inject code that does XHR/fetch, then CORS ''cannot'' save you
 
:: if you included a library from a less-than-trustable site, ''you'' did the bad thing
 
:: if you included a library from a less-than-trustable site, ''you'' did the bad thing
:: if someone steals a domain, good luck <!-- one solution to that one is certificates, and serious sites will probably do that)-->
+
:: if someone steals a domain, good luck
 
: and a few more details beyond that
 
: and a few more details beyond that
 +
 +
* Prevents use of / execution of fetched data, not making a request with an effect in the first place
 +
: so does not prevent basic CSRF
  
 
* Prevents use of / execution of fetched data, not the fetching of the data in the first place.
 
* Prevents use of / execution of fetched data, not the fetching of the data in the first place.
Line 111: Line 120:
 
:: All modern browsers choose to adhere to it, but it's technically still ''advisory''' to the browser and ''can'' be bypassed via browser settings
 
:: All modern browsers choose to adhere to it, but it's technically still ''advisory''' to the browser and ''can'' be bypassed via browser settings
  
* note that it also applies to anything read/fetched by a script.
+
* ...so is '''is absolutely not blanket XSS / CSRF protection'''
:: e.g. a player loading video will be blocked from content - that you could e.g. embed directly
+
: but helps against specific variants.
 +
 
 +
<!--
 +
* For example, if you are banking.example.com and alleviates [[CSRF]] by sending a token, then attackers may want to inject code into users that informs scripting in that browser of that token, and then request something bad.
 +
-->
  
  
Line 120: Line 133:
 
CORS considers that you ''could'' be doing things with custom headers, unusual HTTP methods, etc, for example REST APIs and other protocols on top of HTTP. And that requests can have side effects, e.g. POSTs.
 
CORS considers that you ''could'' be doing things with custom headers, unusual HTTP methods, etc, for example REST APIs and other protocols on top of HTTP. And that requests can have side effects, e.g. POSTs.
  
As such, it allows separation of the consent check (via [[OPTIONS]]), and the data fetch
+
 
 +
As such, it allows separation of the consent check (via [[OPTIONS]]), and the actual interaction (often a data fetch)
 
: useful when the actual request might do a lot of work, or alter state (e.g. is POST), so useful for APIs and protocols built on HTTP
 
: useful when the actual request might do a lot of work, or alter state (e.g. is POST), so useful for APIs and protocols built on HTTP
 
: single-page XHR/fetch can often avoid preflight {{comment|(...though CORS defines the cases, and not ''all'' uses will fit it)}}
 
: single-page XHR/fetch can often avoid preflight {{comment|(...though CORS defines the cases, and not ''all'' uses will fit it)}}

Revision as of 16:12, 10 July 2021

Security related stuff.

Practical


Theory


Unsorted


XSS

Cross-Site Scripting (XSS) refers to a situation where malicious code ends up in otherwise trusted websites.


Generally to the end of making a browser do something you really don't want it to.


See also:


Things that help - while coding

Escaping

Parse your data

Consider CSS

Standards that help

CORS

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

The idea is roughly that initial page loads can do what it wants, but anything that is external and/or executed later needs to be thought about.

It's both about what you are fetching, and when.

As such, embedding images, stylesheets, scripts, iframes, audio and video is generally not restricted.

But things where execution might in some way be involved (e.g. fetching anything via XHR / Fetch, image loads via drawImage embedded fonts, WebGL textures) are restricted via the same-origin policy (SOP), a basic security model that says that these resources must come from the same origin.

Origin here meaning protocol+host+port (because that implies the same web server or at least reverse proxy).


CORS (Cross-Origin Resource Sharing) allows exceptions to that same-origin policy, by having the server end be explicitly okay with a specific request.

In practical terms, CORS is often preferable to

just same-origin (too restrictive if you want e.g. distinct hosts to spread the network load)
disabling same-origin on the browser side (too dangerous, manual work for each user, so isn't going to happen)
subversion same-origin via a server-side script that fetches things for you
because while that works, it's not very efficient, and done wrong it is both a great resource for hackers (open redirects, third-party subversion of same-origin, more)

If you use a CDN, then understanding and using CORS may make your life simpler.


Securitywise

  • The idea behind SOP is that you have to do some work to mix data between different domains, in certain directions
This helps protect against some cases of XSS, but not others
it e.g. often doesn't help if code was injected already
it doesn't prevent giving you executable things - because it's the server, not the page, that says it's okay to execute it.
  • It's not protection against injected "load executable things from here" style XSS, because that injection is already the bad thing, and any server can say "yes okay fine", so e.g.
if someone can inject code that does XHR/fetch, then CORS cannot save you
if you included a library from a less-than-trustable site, you did the bad thing
if someone steals a domain, good luck
and a few more details beyond that
  • Prevents use of / execution of fetched data, not making a request with an effect in the first place
so does not prevent basic CSRF
  • Prevents use of / execution of fetched data, not the fetching of the data in the first place.
You should assume the server sends the data to the browser, along with the advice that it does not execute it.
All modern browsers choose to adhere to it, but it's technically still advisory' to the browser and can be bypassed via browser settings
  • ...so is is absolutely not blanket XSS / CSRF protection
but helps against specific variants.



On the preflight thing

CORS considers that you could be doing things with custom headers, unusual HTTP methods, etc, for example REST APIs and other protocols on top of HTTP. And that requests can have side effects, e.g. POSTs.


As such, it allows separation of the consent check (via OPTIONS), and the actual interaction (often a data fetch)

useful when the actual request might do a lot of work, or alter state (e.g. is POST), so useful for APIs and protocols built on HTTP
single-page XHR/fetch can often avoid preflight (...though CORS defines the cases, and not all uses will fit it)

So API and app developers may up front decide preflight is a better idea


CORS without preflight is simpler to implement

because only
Origin
and
Access-Control-Allow-Origin
are involved
the browser adds Origin (you can't even touch it via scripting, for obvious security reasons)
the server, if it agrees, sends back response header
Access-Control-Allow-Origin
where the value is either:
the Origin URL value it got in the request, or
*
, if the resource is entirely public

Supporting CORS with preflight needs a few more headers, depending on case, probably at least

Access-Control-Allow-Methods (e.g. POST)
Access-Control-Allow-Headers (e.g. Origin, Content-Type)

While CORS's design considers the existence of auth, CORS doesn't handle authentication itself (also limiting the meaning of this authorization)



CSP

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Content-Security-Policy (CSP), roughly, is a server telling a browser what other places it considers safe to load+execute scripts from.


It also extends to media and images so that you can have more lenient rules for them.

This mainly helps reduce XSS issues when using CDNs, in that injected code cannot come from unknown servers (though note that 'known' isn't the same as 'trusted').


Example:

  • Same host (not subdomains)
Content-Security-Policy: default-src 'self'
  • Subdomains too:
Content-Security-Policy: default-src 'self' *.example.com
  • Specific host, and use HTTPS:
Content-Security-Policy: default-src 'self' https://banking.example.com
  • Images from anywhere, media from sister domain, scripts from specific own host
Content-Security-Policy: default-src 'self'; img-src *; media-src *.cdn.example.com; script-src scripts.example.com



https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

https://stackoverflow.com/questions/42922784/what-s-the-purpose-of-the-html-nonce-attribute-for-script-and-style-elements

https://developers.google.com/web/fundamentals/security/csp/

https://caniuse.com/#search=csp

https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet

Privacy concerns

Cookie-like things

"Information you gave to the browser/server that it's storing with you, and sends back verbatim"


It can only store things you already had, and not be used to find out anything new. So it's not a security concern.


Yet it can be a privacy concern, for a few different reasons.


Primarily, many uses of a cookie are to identify when a specific browser re-visits a site.


There are perfectly good uses for this, like "do we stay logged into a site?" (or, say, that a shopping basket you collected while not logged in yet makes it to your account when you log in later), which is a feature a visiting user would want.


An example of a more dubious use is that ad sites historically could collect that a particular browser (so probably person and type of person) would visit the same set of sites, so could serve you ads based on people with similar interests. This will work without ever tying it to any particular person at any point. (this has become much harder to do today, due to stricter cookie policies)


The point of these two examples is that, as a transparent mechanism, good and bad uses happen equally silently. You can disable cookies, but that disables all uses.


Basic browser cookies
Not information theft

Cookies only ever repeat back information (verbatim) that a remote server (or browser script originating from that server) put there. They can never be used to send any other data from your computer, they cannot be used to send data to third parties.


Cookies store (text) data, not executable, so is not something that enables scripts, viruses, adware, or such to work.


Tracking cookies
Cookie overriding
Cookie theft
Flash cookies

Or, as Adobe calls them, Local Shared Objects.

HTML5 SessionStorage
HTML5 Database Storage
MSIE user data persistence
Google Gears

GDPR