Google has been threatening this for a while, but now they’re finally getting around to it; they’re starting to remove Manifest v2 (MV2) from Chromium (and thus Chrome, and likely many browsers based on chromium, which is the majority of the browser space, these days!). What does this mean? Chrome extensions use a set of APIs to talk to the browser engine. The main version that’s been in use for a number of years is “Manifest v2”.
When it comes to talking about API Security there are many facets and paths the conversation can take. We might want to talk about from an AppDev security perspective; after all, an API is just code, so your SAST/DAST type processes apply. We might want to talk about it in terms of authentication; after all, you need credentials to access an API and there’s many different ways this can be done (Basic Auth, mutual TLS, Oauth, HMAC…); this would also include when anonymous APIs are OK!
I got asked a question… this gives me a chance to write an opinion. I have lots of them! If I redirect my port 80 traffic to another site, do I need to get a TLS cert? The question here is related to if a bank (or other service) has changed their name, then do they still need to maintain a TLS site for the old name? Can’t they just have http://mybank.
Last year I wrote about how I used Letsencrypt to handle the SSL certificates for this site. In this entry I’m going to take a step back and discuss the basics of what an SSL certificate is and the steps involved in managing them. There’s a lot of jargon involved, which can make this seem more complicated than it already is. Note that in this post I’m likely to use the words “SSL” and “TLS” interchangeably.
Many people are at a large risk of a phishing attack. In this scenario the person may receive an email that looks like it came from a legitimate source (e.g. their bank) and encourages them to click a link that presents them with their bank login page. The user then attempts to login… Except that site isn’t their banking site. It’s a mockup that looks like the real one. And they’ve now told their banking password to the attacker.
I hit a web page which, naturally, refused to work properly. So I looked at the NoScript report. This one page ws pulling in scripts from (hand-typed so maybe tpyos) adobedtm.com cdna-assets.com chartbeat.com cloudfront.net criteo.com disqus.com disquscdn.com doubleclick.net dunhilltraveldeals.com effectivemeasure.net facebook.com gigya.com google.com googlesyndication.com googletagservices.com imrworldwide.com inksinmedia.com krxd.net mediavoice.com mmcdn.us ooyala.com optimizely.com outbrain.com parsly.com quantserve.com qubitproducts.com revsci.net scorecardresearch.com skimresources.com visualrevenue.com whistleout.com Boggle!
