548 Matching Annotations
  1. Apr 2021
    1. Separate Clusters. It is probably most common to see multiple clusters being deployed. This is due to different reasons, with security focused network segmentation being only one of them. Security focused. Application workloads with different security protection levels can be separated by Kubernetes clusters. This makes isolating traffic easier by using traditional firewalls or VPCs to prevent cross-cluster communication. If connections between clusters are required then it can be manually allowed but management can become cumbersome and error prone. For example, one cluster runs the application workloads and a separate one running databases, file storage (such as S3/minio) and other persistent storage for the same project because different security profiles are required for each cluster.
    1. Note: Building a container image using docker build on-cluster is very unsafe and is shown here only as a demonstration. Use kaniko instead.

      Why?

    1. highly

      This should be much more clearly defined IMHO. At the moment if there are no formal requirements in place, it is possible for an admin of an authorized lab to start using labs private key to issue "validity certificates on the side e.g. for profit"... Much more specifics should be defined about how the private keys are stored / protected (e.g. HSM requirements or other similar requirements which are defined by standards) and also limitations as to if e.g. cloud based HSMs are allowed. Also the security requirement should be strictly defined in the arrangements between WHO and national level authorities as well as between national level authorities and healthcare providers. For smaller countries or countries with centralized EHR with lab results the issuance of keys might end within national authority (as it would be signing the SVCs with its keys and no keys shall be handed over to labs/healthcare providers)

  2. Mar 2021
    1. It is critical you put better_errors only in the development section of your Gemfile. Do NOT run better_errors in production, or on Internet-facing hosts.
    1. here is my set of best practices.I review libraries before adding them to my project. This involves skimming the code or reading it in its entirety if short, skimming the list of its dependencies, and making some quality judgements on liveliness, reliability, and maintainability in case I need to fix things myself. Note that length isn't a factor on its own, but may figure into some of these other estimates. I have on occasion pasted short modules directly into my code because I didn't think their recursive dependencies were justified.I then pin the library version and all of its dependencies with npm-shrinkwrap.Periodically, or when I need specific changes, I use npm-check to review updates. Here, I actually do look at all the changes since my pinned version, through a combination of change and commit logs. I make the call on whether the fixes and improvements outweigh the risk of updating; usually the changes are trivial and the answer is yes, so I update, shrinkwrap, skim the diff, done.I prefer not to pull in dependencies at deploy time, since I don't need the headache of github or npm being down when I need to deploy, and production machines may not have external internet access, let alone toolchains for compiling binary modules. Npm-pack followed by npm-install of the tarball is your friend here, and gets you pretty close to 100% reproducible deploys and rollbacks.This list intentionally has lots of judgement calls and few absolute rules. I don't follow all of them for all of my projects, but it is what I would consider a reasonable process for things that matter.
  3. Feb 2021
    1. By default, hashes remove any keys that aren't given as nested filters. To allow all hash keys, set strip: false. In general we don't recommend doing this, but it's sometimes necessary.
    1. Using an implicit intent to start a service is a security hazard because you can't be certain what service will respond to the intent, and the user can't see which service starts. Beginning with Android 5.0 (API level 21), the system throws an exception if you call bindService() with an implicit intent.
    1. that's a point, but I would say the opposite, when entering credit card data I would rathre prefer to be entirely in the Verified By Visa (Paypal) webpage (with the url easily visible in the address bar) rather that entring my credit card data in an iframe of someone's website.
    1. hilarious sarcasm

    2. My goal (as it turns out) is simply to point out that any site that includes third party code is alarmingly vulnerable, in a completely undetectable way.
    3. I have a Content Security Policy!Oh, do you now.And did somebody tell you that this would prevent malicious code from sending data off to some dastardly domain? I hate to be the bearer of bad news, but the following four lines of code will glide right through even the strictest content security policy.
    4. it is very difficult to spot shenanigans in obfuscated code, you’ve got no chance.
    5. But I’m afraid it’s perfectly possible to ship one version of your code to GitHub and a different version to npm.
    6. The point is, just because you don’t see it, doesn’t mean it’s not happening. It’s been more than two years and as far as I know, no one has ever noticed one of my requests. Maybe it’s been in your site this whole time
    7. Also the URL looks a lot like the 300 other requests to ad networks your site makes.
    8. I’d notice the network requests going out!Where would you notice them? My code won’t send anything when the DevTools are open (yes even if un-docked).I call this the Heisenberg Manoeuvre: by trying to observe the behaviour of my code, you change the behaviour of my code.
  4. Jan 2021
    1. When Snap was introduced Canonical promised it would never replace APT. This promise was broken. Some APT packages in the Ubuntu repositories not only install snap as a dependency but also run snap commands as root without your knowledge or consent and connect your computer to the remote proprietary store operated by Canonical.
    1. Some users download the DEB package and install it manually and manage upgrades completely manually. This is useful in situations such as installing Docker on air-gapped systems with no access to the internet.
    2. The scripts require root or sudo privileges to run. Therefore, you should carefully examine and audit the scripts before running them.
    1. Automatic firmware updates can be accessed from your software settings on System76 hardware. These updates help to promptly quash any threat of security risk to your computer.
    1. Why did I put the kdb in the snap file system? Because the app is sandboxed, so I had no choice.
    2. I run a fairly ancient RedHat Enterprise 6 on my 32-bit test machine and if I need something requiring Gtk3 (such as a latest Firefox or Chrome), I just make a chroot and use debootstrap (from EPEL) to get me a Debian 9 userland for that program. Easy. No bizarre "app stores", no conflicting packages. Do people use Snap app-stores because they don't know how to use the chroot command? Or are they just lazy? If it is because they want the added security of a container, substitute chroot with lxc... Shouldn't be necessary though; if you avoid non-ethical software (i.e App-stores), you are very unlikely to need the added security.
    3. By design, snap apps have no access to /etc. They live in their own little world, but instead of a normal chroot, they are splatted all over the standard Linux filesystem layout. With other bits mounted hither and thither. Its a mess, and subject to change with each release.
    1. "in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can't audit them, hold them, modify them or even point snap to a different store. You've as much empowerment with this as if you were using proprietary software, i.e. none."
    1. At least one Zoom leaker has already been unmasked: a member of the New York State Assembly who apparently filmed his “self-view” while recording a dispute within the Democratic assembly conference over the renomination of the speaker. That may sound careless, but a feature developed by Zoom will allow future leakers to be exposed even without that sort of misstep.
    1. I remember reading Matt Bruenig when I was in college, and he was like, “Well, actually Social Security was the most effective pathway to bring people out of poverty.”  I wrote a story in 2017 called “Why Education Is Not the Key to a Good Income,” and it was looking at this growing body of research that showed it was not your level of education that determined your chances of rising economic mobility. It was these other factors—like what kind of industries were in your community, union density, some of it was marriage. 

      makes sense... the best way out of poverty isn't education... it's money.

  5. atomiks.github.io atomiks.github.io
    1. The CSS automatically gets injected into <head> with the CDN (tippy-bundle). With CSP enabled, you may need to separately link dist/tippy.css and use dist/tippy.umd.min.js instead.
    1. Ensure HTML strings containing user data are sanitized properly to prevent XSS attacks.
    1. JSONP is a relic of the past and shouldn’t be used due to numerous limitations (e.g., being able to send GET requests only) and many security concerns (e.g., the server can respond with whatever JavaScript code it wants — not necessarily the one we expect — which then has access to everything in the context of the window, including localStorage and cookies).
    1. The application is executed in an encapsulated, ring-fenced way, so its files can’t interfere with those on your computer. You can even install multiple versions of the same application, and they won’t cross-pollinate or fight amongst themselves.
    1. Many people are also very wary of PPAs because they can contain anything. While a PPA might say it contains “Music Player”, the owner of the PPA can put anything in it. The deb installed from a PPA has root on your system when installed, so can do anything - good or bad.
    2. but that doesn’t mean that confining applications is not a benefit also to FOSS applications, security is an issue that needs to be addressed with many layers of measures no mater what licensing approach you use to license the software
    3. However there’s more benefit of confining proprietary closed source applications, because they are to audit to the same level
    4. The benefits for developers do reflect on benefits for users, with more software delivered faster and more securely.
    5. But in my apt/deb world, where I use official repositories from my distro, where is the threat from 3rd party ? They are eventually « curated » in partner repository, or in universe
    6. Adding layer of settings and complexity for the end user might also bring bad practices to keep a comfortable use of app’s by installing snap without confinement…
    1. As you already noticed, the extension does not go in an manipulate the hrefs/urls in the DOM itself. While it may seem scary to you that an extension may manipulate a URL you're navigating to in-flight, I think it's far scarier to imagine an extension reading and manipulating all of the HTML on all of the pages you go to (bank accounts, utilities, crypto, etc) in order to provide a smidgeon of privacy for the small % of times you happen to click a link with some UTM params.
    1. When you use target="_blank" with Links, it is recommended to always set rel="noopener" or rel="noreferrer" when linking to third party content. rel="noopener" prevents the new page from being able to access the window.opener property and ensures it runs in a separate process. Without this, the target page can potentially redirect your page to a malicious URL. rel="noreferrer" has the same effect, but also prevents the Referer header from being sent to the new page. ⚠️ Removing the referrer header will affect analytics.
  6. Dec 2020
    1. The only solution that I can see is to ensure that each user gets their own set of stores for each server-rendered page. We can achieve this with the context API, and expose the stores like so: <script> import { stores } from '@sapper/app'; const { page, preloading, session } = stores(); </script> Calling stores() outside component initialisation would be an error.

      Good solution.

    2. One way to do that is to export them from @sapper/app directly, and rely on the fact that we can reset them immediately before server rendering to ensure that session data isn't accidentally leaked between two users accessing the same server.
    1. This would be cumbersome, and would encourage developers to populate stores from inside components, which makes accidental data leakage significantly more likely.
    2. Just realised this doesn't actually work. If store is just something exported by the app, there's no way to prevent leakage. Instead, it needs to be tied to rendering, which means we need to use the context API. Sapper needs to provide a top level component that sets the store as context for the rest of the app. You would therefore only be able to access it during initialisation, which means you couldn't do it inside a setTimeout and get someone else's session by accident:
    1. This is an opportunity to fix a bug: if you're on a page that redirects to a login page if there's no user object, or otherwise preloads data specific to that user, then logging out won't automatically update the page — you could easily end up with a page like HOME ABOUT LOG IN ----------------------------------------------------------------------------------------- Secret, user-specific data that shouldn't be visible alongside a 'log in' button:
    1. Go is introducing publicly-visible API changes related to these issues in an upcoming major release, which risks making the vulnerabilities public without explicit public disclosure. 

      Whaaat ?!

    1. The only completely secure system is the one that doesn't exist in the first place.
  7. Nov 2020
    1. to be listed on Mastodon’s official site, an instance has to agree to follow the Mastodon Server Covenant which lays out commitments to “actively moderat[e] against racism, sexism, homophobia and transphobia”, have daily backups, grant more than one person emergency access, and notify people three months in advance of potential closure. These indirect methods are meant to ensure that most people who encounter a platform have a safe experience, even without the advantages of centralization.

      Some of these baseline protections are certainly a good idea. The idea of advance notice of shut down and back ups are particularly valuable.

      I'd not know of the Mastodon Server Covenant before.

    1. @hypothes.is

      be careful : because you store the page title, when we make annotation on a personal website that stores personal informations in title, hypothes.is users can retieve those informations.

      for example, here I can see that jbarnett mail is jeankap@gmail.com.

      and i can see his mail's title.

      I will find a report option that would be better than this current annotation.

    1. This is addressing a security issue; and the associated threat model is "as an attacker, I know that you are going to do FROM ubuntu and then RUN apt-get update in your build, so I'm going to trick you into pulling an image that ​_pretents_​ to be the result of ubuntu + apt-get update so that next time you build, you will end up using my fake image as a cache, instead of the legit one." With that in mind, we can start thinking about an alternate solution that doesn't compromise security.
    2. So let's say we pull down evil/foo which is FROM ubuntu followed by RUN apt-get update except with a small surprise included in the image. Subsequent builds using those same commands will be compromised.
    3. at least in the meantime allow users to bypass the security protections in situations where they are confident of the source of the layers
    1. If your Svelte components contain <style> tags, by default the compiler will add JavaScript that injects those styles into the page when the component is rendered. That's not ideal, because it adds weight to your JavaScript, prevents styles from being fetched in parallel with your code, and can even cause CSP violations. A better option is to extract the CSS into a separate file. Using the emitCss option as shown below would cause a virtual CSS file to be emitted for each Svelte component. The resulting file is then imported by the component, thus following the standard Webpack compilation flow.
    1. Now let me get back to your question. The FBI presents its conflict with Apple over locked phones as a case as of privacy versus security. Yes, smartphones carry a lot of personal data—photos, texts, email, and the like. But they also carry business and account information; keeping that secure is really important. The problem is that if you make it easier for law enforcement to access a locked device, you also make it easier for a bad actor—a criminal, a hacker, a determined nation-state—to do so as well. And that's why this is a security vs. security issue.

      The debate should not be framed as privacy-vs-security because when you make it easier for law enforcement to access a locked device, you also make it easier for bad actors to do so as well. Thus it is a security-vs-security issue.

    1. Barr makes the point that this is about “consumer cybersecurity” and not “nuclear launch codes.” This is true, but it ignores the huge amount of national security-related communications between those two poles. The same consumer communications and computing devices are used by our lawmakers, CEOs, legislators, law enforcement officers, nuclear power plant operators, election officials and so on. There’s no longer a difference between consumer tech and government tech—it’s all the same tech.

      The US government's defence for wanting to introduce backdoors into consumer encryption is that in doing so they would not be weakening the encryption for, say, nuclear launch codes.

      Schneier holds that this distinction between government and consumer tech no longer exists. Weakening consumer tech amounts to weakening government tech. Therefore it's not worth doing.

  8. Oct 2020
    1. Malicious code pushed to your .gitlab-ci.yml file could compromise your variables and send them to a third party server regardless of the masked setting. If the pipeline runs on a protected branch or protected tag, it could also compromise protected variables.
    1. Australia's Cyber Security Strategy: $1.66 billion dollar cyber security package = AFP gets $88 million; $66 million to critical infrastructure organisations to assess their networks for vulnerabilities; ASD $1.35 billion (over a decade) to recruit 500 officers.

      Reasons Dutton gives for package:

      • child exploitation
      • criminals scamming, ransomware
      • foreign governments taking health data and potential attacks to critical infrastructure

      What is defined as critical infrastructure is expanded and subject to obligations to improve their defences.

      Supporting cyber resilience of SMEs through information, training, and services to make them more secure.

    1. Could you please explain why it is a vulnerability for an attacker to know the user names on a system? Currently External Identity Providers are wildly popular, meaning that user names are personal emails.My amazon account is my email address, my Azure account is my email address and both sites manage highly valuable information that could take a whole company out of business... and yet, they show no concern on hiding user names...

      Good question: Why do the big players like Azure not seem to worry? Microsoft, Amazon, Google, etc. too probably. In fact, any email provider. So once someone knows your email address, you are (more) vulnerable to someone trying to hack your account. Makes me wonder if the severity of this problem is overrated.

      Irony: He (using his full real name) posts:

      1. Information about which account ("my Azure account is my email address"), and
      2. How high-value of a target he would be ("both sites manage highly valuable information that could take a whole company out of business...")

      thus making himself more of a target. (I hope he does not get targetted though.)

    2. Another thing you can do is to add pain to the second part of it. Attackers want the list of valid usernames, so they can then try to guess or brute force the password. You can put protections in place with that as well, whether they are lockouts or multi-factor authentication, so even if they have a valid username, it's much harder to gain access.
    3. That is certainly a good use-case. One thing you can do is to require something other than a user-chosen string as a username, something like an email address, which should be unique. Another thing you could do, and I admit this is not user-friendly at all, to let them sign up with that user name, but send the user an email letting them know that the username is already used. It still indicates a valid username, but adds a lot of overhead to the process of enumeration.
    1. How would you remediate this? One way could be to have the application pad the responses with a random amount of time, throwing off the noticeable difference.
    2. Sometimes, user enumeration is not as simple as a server responding with text on the screen. It can also be based on how long it takes a server to respond. A server may take one amount of time to respond for a valid username and a very different (usually longer) amount of time for an invalid username.
    1. By default all content inside template strings is escaped. This is great for strings, but not ideal if you want to insert HTML that's been returned from another function (for example: a markdown renderer). Use nanohtml/raw for to interpolate HTML directly.
    1. strict-origin: Only send the origin of the document as the referrer when the protocol security level stays the same (e.g. HTTPS→HTTPS), but don't send it to a less secure destination (e.g. HTTPS→HTTP).
  9. Sep 2020
    1. There are clever ways around trackers

      I also recommend switching to FIrefox, getting the Facebook container extension and Privacy Badger extension!

    2. These creeping changes help us forget how important our privacy is and miss that it’s being eroded.

      This is important we are normalizing the fact that our privacy is being taken slowly, update after update

  10. Aug 2020
  11. Jul 2020
    1. While stylesheets can be reworked relatively easily with AMP by inlining the CSS, the same is not true for JavaScript. The tag 'script' is disallowed except in specific forms. In general, scripts in AMP are only allowed if they follow two major requirements: All JavaScript must be asynchronous (i.e., include the async attribute in the script tag). The JavaScript is for the AMP library and for any AMP components on the page. This effectively rules out the use of all user-generated/third-party JavaScript in AMP except as noted below.
    1. If you have worked with emails before, the idea of placing a script into an email may set off alarm bells in your head! Rest assured, email providers who support AMP emails enforce fierce security checks that only allow vetted AMP scripts to run in their clients. This enables dynamic and interactive features to run directly in the recipients mailboxes with no security vulnerabilities! Read more about the required markup for AMP Emails here.
    1. Determine if who is using my computer is me by training a ML model with data of how I use my computer. This is a project for the Intrusion Detection Systems course at Columbia University.