The sorry state of OpenSSL usability

OpenSSL is a widely used but poorly documented software, making it difficult for users to figure out how to use basic functionality like generating an RSA key. The documentation is scattered across multiple websites, often contradictory, and assumes a level of cryptographic knowledge that many users lack. Even simple tasks like determining the key format can be challenging due to the lack of clear guidance. The author highlights several usability issues with OpenSSL, such as the default use of a weak 512-bit RSA key, and the lack of warnings or guidance when using deprecated interfaces. The author argues that improving OpenSSL's usability through better documentation, user testing, and avoiding unnecessary forks could go a long way in making this critical piece of software more accessible to a wider audience.

https://jameshfisher.com/2017/12/02/the-sorry-state-of-openssl-usability/

@DevMisc
#cryptography #openssl #learn

Replacing FastAPI with Rust — A series

The author is starting a blog series exploring the possibility of replacing the FastAPI Python web framework with the Rust programming language for their use case. FastAPI is the author's go-to backend framework, but they are interested in moving beyond some of the limitations of Python. The key requirements the author is hoping to achieve with a Rust-based solution are high performance, type safety, and ease of deployment. The author is unsure where this exploration will lead, but is excited to document the process and see if they can create a compelling alternative to FastAPI. Readers are encouraged to follow along, provide feedback, and suggest ideas for the blog series.

1. Intro (defining requirements)
2. Research (rweb, rocket, paperclip)
3. Trying Actix (actix-web)
4. A Solution (rweb, dropshot, rocket with okapi)
5. Rocket 0.5 (rocket, async tests, memory management)
6. AWS Lambda (AWS CDK)

@DevMisc
#rust #fastapi #rocket #learn

Understanding Rust futures by going way too deep 🦀

The text is a deep dive into understanding Rust futures. It starts by setting up a basic Rust project and adding dependencies like tokio, color-eyre, and tracing. It then demonstrates how to make a simple HTTP request using the reqwest library. The author explains that futures in Rust are just state machines that don't do anything until they are polled, which is demonstrated through creating a "dumb future". The text then dives deeper into the internals of Rust futures, showing how to inspect the call stack when things go wrong, even using unsafe code to cause a segmentation fault. The overall message is that Rust futures are powerful but require understanding their underlying mechanics to use them effectively.

https://fasterthanli.me/articles/understanding-rust-futures-by-going-way-too-deep

@DevMisc
#rust #async #learn

So you want to deploy mTLS

mTLS is just like TLS, but with one extra consideration. In mTLS, both the client and server are authenticated, whereas in standard TLS only the server is authenticated. That’s where the m comes from: mutual.

https://otterize.com/blog/so-you-want-to-deploy-mtls

@DevMisc
#cryptography #security #tls #learn

Cursed Knowledge

Things we wish we didn't know.

https://immich.app/cursed-knowledge/

@DevMisc
#fun #misc #learn

Understanding and Preventing Race Conditions in Web Applications

- Race conditions can lead to data corruption, crashes, and security vulnerabilities if not properly addressed.
- Using a simple increment operation to update a shared counter is vulnerable to race conditions and can result in incorrect counts.
- Locking the database row using "SELECT FOR UPDATE" is not sufficient to prevent race conditions, as it does not guarantee atomicity.
- Transactions are essential to ensure atomicity and prevent race conditions, but simply using a transaction is not enough - the specific SQL query used must also be atomic.
- Updating the counter using an atomic SQL query (e.g. "UPDATE table SET views = views + 1 WHERE id = $1") is a more scalable and efficient solution compared to locking rows.
- When dealing with game economies and player balances, it's crucial to enforce constraints at the database level (e.g. CHECK constraints) to prevent negative balances.
- Transactions do not inherently prevent all race conditions - the specific implementation and isolation level used is important.
- Avoid using "LOCK TABLE" as it can lead to performance issues and scalability problems.
- Testing for race conditions by simulating concurrent requests is essential to identify and address such issues.
- There is no single silver bullet solution - each approach has trade-offs that must be carefully considered based on the specific requirements of the application.

https://gavide.hashnode.dev/prevent-race-conditions-in-your-api

@DevMisc [#Original ❤️]
#security #sql #backend #learn

Gaining access to anyones browser without them even visiting a website

- Arc Browser
- arc boosts can contain arbitrary javanoscript
- arc boosts are stored in firestore
- the arc browser gets which boosts to use via the creatorID field
- we can arbitrarily chage the creatorID field to any user id
- $2000 bounty
- possible RCE with xss on privileged pages (chrome://settings)
- arc sends every url you visit to firebase queries

https://kibty.town/blog/arc/

@DevMisc
#security #firebase #learn

Using YouTube to steal your files

The document describes a security researcher's discovery of a vulnerability chain that allows stealing files using Google Slides and YouTube. The attack involves chaining a path traversal in the YouTube embed feature of Google Slides, open redirects on YouTube and Google accounts, and a trick to bypass protections on Google Docs pages. The researcher was able to create a one-click attack that tricks the user into granting editor access to a targeted Google Drive file or folder. The vulnerability was reported to Google and the researcher received a $4,133.70 reward.

https://lyra.horse/blog/2024/09/using-youtube-to-steal-your-files/

@DevMisc
#security #bugbounty #misc

@DevMisc
#meme #sql #extra

@DevMisc
#meme #c #extra

$50k how Zendesk left a backdoor in Fortune 500 companies

- Zendesk Vulnerability: A single bug in Zendesk allowed attackers to access customer support tickets from various Fortune 500 companies due to inadequate email spoofing protection.
- Security Risks: Connecting Zendesk to company domains used for Single Sign-On (SSO) created potential security gaps, enabling unauthorized access to internal systems.
- Email Spoofing Exploit: The vulnerability exploited Zendesk's ticketing system, where attackers could impersonate legitimate users and gain full access to ongoing support conversations.
- Bug Bounty Program Issues: Initial reporting of the vulnerability through Zendesk's bug bounty program was rejected as "out of scope," highlighting flaws in their triage process.
- Escalation to Slack Access: The author replicated a previous exploit to gain access to private Slack channels of multiple companies by leveraging the same vulnerability in conjunction with Apple's email verification process.
- Complex Attack Steps: The attack required meticulous planning, including creating accounts and spoofing emails to exploit the vulnerability effectively.
- Pressure on Zendesk: The author reported the vulnerability to affected companies, which pressured Zendesk to take action, leading to eventual acknowledgment and a fix after months of delay.
- Financial Rewards: The author earned over $50,000 in bug bounties from individual companies for reporting the vulnerability, despite Zendesk refusing to award any bounty.
- Zendesk's Response: After a lengthy period, Zendesk implemented fixes, including improved spam filtering and sender authentication, but did not recognize the initial report.
- Bug Hunting Reality: The experience underscores the unpredictable nature of bug hunting, where outcomes can vary significantly, and recognition may not always follow successful disclosures.

https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52

@DevMisc
#security #bugbounty #writeup #misc

@DevMisc | #meme #godot

The trailing dot in domain names matter

- Trailing Dot in Domain Names: A trailing dot can be added to a domain name, designating it as a Fully Qualified Domain Name (FQDN), which specifies its exact position in the DNS hierarchy.
- FQDN vs. Non-FQDN: The presence of a trailing dot distinguishes between a fully qualified domain name (e.g., example.com.) and a regular domain name (e.g., example.com), which can lead to different behaviors in DNS resolution.
- Local Network Behavior: On local networks, omitting the domain can lead to confusion, as local DNS resolvers may append local domain names to requests, affecting how services are accessed.
- SEO Considerations: Both FQDN and non-FQDN versions of a domain can be indexed by search engines, potentially causing duplicate content issues, which can negatively impact SEO rankings.
- Redirect Strategies: There are two main strategies for handling redirects between FQDN and non-FQDN versions: redirecting to the FQDN (technically correct) or the non-FQDN (more user-friendly), each with its pros and cons.
- Browser Behavior: Browsers treat FQDN and non-FQDN as distinct domains, which can lead to unexpected behavior, such as users being logged out when switching between them.
- Content Serving Issues: Without specific configurations, servers may serve duplicate content for both FQDN and non-FQDN, risking SEO penalties and user confusion.
- SSL Certificate Validations: Many websites fail to properly handle SSL certificates for both FQDN and non-FQDN versions, leading to errors and security issues for users.
- Large Website Practices: A review of major websites reveals inconsistent handling of trailing dots, with varying responses for FQDN and non-FQDN requests, often leading to user frustration.
- Recommendations for Handling: Best practices include ensuring proper SSL configurations, serving 2xx responses on FQDN, and implementing effective redirection strategies to mitigate potential issues related to trailing dots in domain names.

https://lacot.org/blog/2024/10/29/the-trailing-dot-in-domain-names-a-detail-that-is-often-poorly-managed.html

@DevMisc
#dns #web #learn

Component Party

Web component JS frameworks overview by their syntax and features: Svelte 5, React, Vue 3, Angular Renaissance, Angular, Lit, Ember Octane, Solid.js, Svelte 4, Vue 2, Alpine, Ember Polaris (preview), Mithril, Aurelia 2, Qwik, Marko, Aurelia 1

https://component-party.dev/

@DevMisc
#web #learn #misc

Does Your Code Pass The Turkey Test?

The article discusses the importance of writing code that can handle cultural differences, using Turkey as an example. The author highlights several common programming pitfalls that can arise when software is used in Turkey, such as issues with date formatting, decimal separators, and character encoding. The article provides specific examples of these problems and explains how to properly address them by following best practices for internationalization and localization. The key takeaway is that if your code can handle the unique quirks of the Turkish market, it will likely work well in most other regions as well. The article serves as a useful reminder to always consider cultural nuances when developing software for a global audience.

https://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html

@DevMisc
#bugs #csharp #misc

@DevMisc
#meme #ai #ml #extra

@DevMisc (src)
#meme #code #extra

Bybit Hack Report ($1.4B ETH heist)

https://docsend.com/view/s/rmdi832mpt8u93s7

@DevMisc
#security #crypto #misc