I make and sell BusKill laptop kill cords. Monero is accepted.

https://michaelaltfield.net

  • 234 Posts
  • 92 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle


  • https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html

    I haven’t seen it. Thanks for sharing!

    afaik, it doesn’t cover this use-case (where the Resource Server [Stripe] just uses the wrong flow – forcing us to expose our access keys to a third party).

    But, curious, it lists 0 attacks for the OAuth Flow that Stripe should be using here = Client Credentials Flow.

    Edit: ahhhhh, this paragraph is elucidating

    The Authorization Code Flow is one of the most widely used OAuth flows in web applications. Unlike the Implicit Flow, which requests the Access Token directly to the Authorization Server, the Authorization Code Flow introduces an intermediary step. In this process, the User Agent first retrieves an Authorization Code, which the application then exchanges, along with the Client Credentials, for an Access Token. This additional step ensures that only the Client Application has access to the Access Token, preventing the User Agent from ever seeing it.

    I confirmed that Stripe is using the Authorization Code Flow

    curl https://connect.stripe.com/oauth/token \
    -u sk_test_MgvkTWK1jRG3olSRx9B7Mmxo: \
    -d “code”=”ac_123456789” \
    -d “grant_type”=”authorization_code”
    

    …but it does appear to be using the wrong OAuth Flow type. They give the token to us in the end. There’s no need to expose it to a third party.

    So I guess “choosing the wrong flow type” would be a valid addition to the “attacks” section under Authorization Code Flow



  • Thanks. It’s a good guess, but that’s not the case.

    The developers confirmed that the only place the OAuth access tokens are stored is on my server. Of course, the dev’s server (which sees the [non-expiring!] access keys for >800,000 Stripe Accounts!) would be a ripe target for someone malicious. But it’s not designed to store the keys there. All subsequent connections to the Stripe API are done directly between my server and Stripe’s server (with no intermediary “platform”). The token is only exposed to the dev server when OAuth flow is first established. Then the dev server (effectively a MITM, by design) sends it down to my server for storing and future use.

    PCI compliance on my server isn’t an issue because all sensitive payment information is tokenized.

    The reason this is done is because Stripe doesn’t allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that’s hard-coded into the app.

    For security purposes, Stripe redirects a user only to a predefined URI.

    That’s why Stripe forces you to expose your access tokens to the developer’s servers.

    I’d still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer’s servers.

    Update: It looks like you’re describing their “Platform” option. In 2025, there’s 3 “authentication types” for Stripe Apps, as documented here

    1. Platform
    2. OAuth 2.0
    3. Restricted API Keys

    In this case, I’m talking about OAuth 2.0 (Stripe Connect), not “Platform”


  • I have been, but Stripe support hasn’t been helpful.

    Update: one of the plugin authors finally explained it well:

    It’s because Stripe doesn’t allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that’s hard-coded into the app.

    For security purposes, Stripe redirects a user only to a predefined URI.

    That’s why Stripe forces you to expose your access tokens to the developer’s servers.

    I’d still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer’s servers.




















  • Yeah, it’s dangerous for a community to tolerate and adopt closed-source software. We should have done a better job pressuring them to license it openly.

    The OSM wiki pointed me to Maperitive first, but I wish it pointed me to qgis first. We should probably edit the wiki with a huge warning banner that the code is closed, the app is full of bugs, and that it is not (and can not be) updated.

    Edit: I took my own advice and added a big red box to the top of the article warning the user and pointing them to QGIS instead.

    Edit 2: Do we have any way to know when the latest version of Maperitive (v2.4.3) was released? Usually I’d check the git repo, but…

    Edit 3: stat on the Maperitive-latest.zip file says that it’s last modified 2018-02-27 17:25:07, so it’s at least 6 years old.









  • maltfieldOPtoDocker@selfhosted.forumHow to wget/curl docker images
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    8 months ago

    what happens if I die? what happens if my site goes down? what happens if a site is “protected” by cloudflare (and therefore makes the content inaccessible to at-risk folks)? what happens if a site has an authwall (and therefore is inaccessible to less-privileged folks)?

    I think it’s important for us to federate content, not just links.




  • maltfieldOPtoSolarDIY@lemmy.worldHelp designing a *large* solar system
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    11 months ago

    We’re not looking to be tied to a grid outside the community. Do you have any links to recommended resources to learn more about microgrids and/or community grids?

    If it were me and I understand correctly I would probably not tie the systems together.

    Well, the loads of the buildings are different, so tieing them together would be very beneficial. For example, one building is a workshop with lots of power tools and heavy machinery and some other buildings (with equal sq meter rooftops) are residential (with less energy requirements)



  • Got it. But I just wouldn’t say it’s futile. The case of a KYC Selfie is especially bad, but the case of a nude is a better example of the usefulness of implementing a federated delete request.

    There’s so much porn on the fediverse. Yes, It’s conceivable that some admins will patch their instance to ignore (or specifically give special attention-to) images that have received federated delete requests from other instances – but I don’t think there’s much incentive in them doing that for nudes when there’s already a firehose of other nudes incoming.

    Even in the case where the image already federated, I think that implementing better data privacy functionality for images (including federated delete requests) would significantly reduce the harm of users and instance admins in 99% of cases. It’s not futile. Reducing harm is important and worthwhile.



  • o hai. Curious that you expected a bunch of people to support you within a couple days. I never saw your proposal (buried in a comment thread in one post on lemmy). I’m only first hearing of this 6 hours after you specifically tagged me. I think you could do more to publish & advocate your proposals if you’re serious about them…

    Before the incident described in the article you’re referencing, I had never spoken to any instance admins. Since I published it, I have spoken to several instance admins (many reached out to me), and they all expressed similar frustrations with the lemmy devs and fatigue in contributing to this project.

    No matter how much people will tell you that something is important to them, the true test is seeing how many are willing to pay the asking price.

    I think it’s important to consider that there’s many ways that people contribute to Lemmy. Equally as important as the work that the devs are doing is the work that the instance admins are doing. Collectively the community of instance admins are contributing much more money and time into lemmy than the developers are. That shouldn’t be discounted. Both should be appreciated.

    There are other ways that people take time out of their lives to support Lemmy, such as finding and filing bug reports, writing documentation, answering questions about the fediverse to new users, raising awareness about lemmy on other centralized platforms, etc. These are also all contributions that benefits the project. Don’t discount them.

    But when our contributions are met with disrespect, it pushes us away. Based on my conversations with countless Lemmy contributors in the past few days, that’s where a lot of people are. They don’t want to invest any more time or money into Lemmy because of their previous interactions with the Lemmy devs.

    This can be repaired, but the Lemmy devs do need to work on fixing their Image Problem.