400 karma · joined February 6, 2009
Encarta (used) - Never used it much, I got it pretty cheap. I was so impressed by the amount of information available on 1 CD
Corel Suite - Also cheap, I believe it came with WordPerfect
Moe important, the list of issues would be the same for a session cookie: if you don't expire the session on the back-end or reflect changes in the user attributes, same issue.
Basically, apply the same best practices for session tokens or JWT token and you'll be fine. You can also put the JWT toke in the cookie, it does not have to be stored in the browser local stroage.
1. Put the intercepting SSL cert root in your local trusted store. This is how it is done in enterprise. The certificate is typically pushed through an MDM installed on each computer/phone. This is also how Fiddler works. This requires administrative access to your device to push the certificate root as trusted.
2. Create a rogue certificate from an existing trusted certificate registrar. This is why is a risk with nations like China where "private" SSL registars mybe forced to issue certificates for Google or other sites to the government. This was supposed to be fixed with Certificate pinning (now deprecated), and now with certificate transparency log. But the later has a few weaknesses in practice: - rarely set as enforced by the websites, or set at at all - requires each company to monitor the transparency log and get rogue certificate canceled. I don't know of any company which actually does that.
3. Interception inside the browser through an extension or plugin, or plain process hijack. Since the browser does the HTTPS encryption/decryption, an application taht runs inside the browser with the right access can see all decrypted traffic.
Spoiler: time in market beats timing the market, historycally.
I think net worth is important to calculate your retirement age.
The basic security in we browsers is based on SoP: Separation of Origins. To simplify, there are number of actions that can be done within an origin (a domain, to simplify) that are prevented across origins (across domains, to simplify). CORS is way for bridge 2 different origins, i.e.e to allow some specific actions between 2 different origins.
One example: by default, XHR requests can only send a specific set of HTTP headers to a different origin. If b.com want to accept the header X-Special-Header from a.com, it has to whitelist it - Access-Control-Allow-Headers: X-Special-Header, Access-Control-Allow-Origin: a.com. On a.com, before the web browser makes an XHR request to b.com that includes the header X-Special-Header, it has to check whether b.com authorizes it or not. I sends an OPTIONS request to b.com and check for the HTTP response headers Access-Control-Allow-Origin and Access-Control-Allow-Headers.
Since CORS is a way to bypass the Separation of Origin basic security model, you should be careful with it. For example, you may allow any site to get read your content, i.e. trigger a CSRF request on behalf of the user logged in to bank.com, and with Javascript be able to read the page content, including the account number because bank.com set the CORS to authorize any remote site to do anything, basically putting bank.com in the same origin as any other domain.