Posts Tagged ‘Security’

Pierre Tondereau, a developer with a passion for exploring new technologies, captivated attendees at PHP Forum Paris 2022 with his engaging exploration of creating PHP extensions using Rust. Drawing from his personal journey of discovering Rust in 2021, Pierre shared a compelling narrative about leveraging this modern language to enhance PHP’s capabilities. His presentation, rooted in a practical experiment, highlighted Rust’s potential to improve security and streamline development, offering a fresh perspective on extending PHP’s functionality.

Why Rust for PHP Extensions?

Pierre began by introducing Rust, a language developed by Mozilla in 2015 to refactor their HTML rendering engine, prioritizing performance and memory safety. Unlike traditional PHP extensions written in C, which demand meticulous memory management to avoid security vulnerabilities, Rust offers robust safety guarantees. Pierre explained how Rust’s design eliminates common issues like null pointer dereferences, making it an appealing choice for PHP developers unfamiliar with C’s complexities. He emphasized that his goal was not to rewrite PHP’s virtual machine but to create a secure, efficient extension using the ext-php-rs crate.

Building and Distributing Extensions

Delving into the technical process, Pierre outlined how the ext-php-rs crate simplifies PHP extension development by abstracting the Zend API. He demonstrated wrapping Rust APIs for PHP userland, using tools like cargo-php to streamline building and installation. Pierre highlighted the crate’s comprehensive coverage, which handled his use case effectively, though he encouraged community feedback to expand its capabilities. By automating distribution, Rust enables developers to integrate extensions seamlessly, enhancing PHP’s ecosystem with minimal friction.

Security and Future Potential

Concluding, Pierre underscored Rust’s security benefits, citing its ability to prevent memory-related vulnerabilities that plague C-based extensions, such as those impacting Google Chrome. He referenced Microsoft’s 2019 shift toward prioritizing security over performance, reinforcing Rust’s relevance. Pierre invited developers to explore his GitHub repository and contribute to ext-php-rs, fostering a collaborative push toward safer, more reliable PHP extensions. His talk inspired attendees to consider Rust as a viable tool for modernizing PHP development.

Links:

• ext-php-rs on GitHub

At Devoxx France 2022, Mathieu Humbert, a tech lead at Accenture with over 15 years of development experience, navigates the complex landscape of HTTP security headers. Mathieu demystifies headers like CSP, HSTS, XFO, and CORS, explaining their role in protecting web applications from threats like XSS, CSRF, and SSRF. Through a clear and engaging presentation, he outlines common attacks, their risks, and how specific headers can mitigate them, concluding with practical tools and resources for implementation.

Understanding HTTP Security Headers

Mathieu begins by introducing HTTP security headers as critical tools for safeguarding web applications. He explains headers like Content Security Policy (CSP), which restricts the sources from which content can be loaded, and HTTP Strict Transport Security (HSTS), which enforces HTTPS connections. These headers, though complex, are essential for mitigating risks in an ever-evolving threat landscape. Mathieu’s experience at Accenture informs his approach, emphasizing that understanding the purpose of each header is key to effective implementation.

By mapping headers to specific threats, Mathieu provides clarity on their practical applications. For instance, Cross-Site Scripting (XSS) attacks, where malicious scripts are injected into web pages, can be mitigated with CSP, while Cross-Site Request Forgery (CSRF) risks are reduced through proper header configurations. His accessible explanations make the technical subject approachable, ensuring developers grasp the importance of these defenses.

Mitigating Common Web Attacks

Delving into specific attacks, Mathieu outlines how headers counter vulnerabilities. He discusses XSS, where attackers exploit input fields to inject harmful code, and CSRF, where unauthorized actions are triggered on behalf of users. Headers like X-Frame-Options (XFO) prevent clickjacking by restricting how pages are framed, while CORS configurations ensure safe cross-origin requests. Mathieu also addresses Server-Side Request Forgery (SSRF), highlighting headers that limit unauthorized server requests.

Through real-world examples, Mathieu illustrates the consequences of neglecting these headers, such as data breaches or session hijacking. He stresses that proactive header implementation can significantly reduce these risks, providing a robust first line of defense for web applications. His insights, drawn from years of tackling technical challenges, underscore the necessity of staying vigilant in a dynamic threat environment.

Practical Implementation and Tools

Mathieu offers actionable guidance for integrating security headers into development workflows. He recommends starting with tools like OWASP’s Security Headers Project, which provides comprehensive documentation for configuring headers effectively. For testing, he suggests platforms like WebGoat, designed to simulate vulnerabilities, allowing developers to practice identifying and fixing issues. Mathieu also highlights the importance of automated scanners, such as Burp Suite, to detect missing or misconfigured headers.

His experience with distributed architectures and agile teams at Accenture informs his practical approach. Mathieu advises incremental implementation, starting with critical headers like HSTS and CSP, and regularly reviewing configurations to adapt to new threats. This methodical strategy ensures that security remains a priority without overwhelming development teams.

Links:

• Accenture company website
• Mathieu Humbert’s blog
• OWASP Security Headers Project

Hashtags: #WebSecurity #HTTPHeaders #Cybersecurity #DevoxxFR2022 #MathieuHumbert #Accenture #OWASP

At Devoxx France 2022, Emmanuel Lécharny, Jean-Baptiste Onofré, and Hervé Boutemy, all active contributors to the Apache Software Foundation, tackle the infamous Log4Shell vulnerability that shook the tech world in December 2021. Their collaborative presentation dissects the origins, causes, and responses to the Log4J security flaw, addressing whether the Apache Foundation bears responsibility. By examining the incident’s impact, the trio provides a transparent analysis of open-source security practices, offering insights into preventing future vulnerabilities and fostering community involvement. Their expertise and candid reflections make this a vital discussion for developers and organizations alike.

Unpacking the Log4Shell Incident

Emmanuel, Jean-Baptiste, and Hervé begin by tracing the history of Log4J and the emergence of Log4Shell, a critical vulnerability that allowed remote code execution, impacting countless systems worldwide. They outline the technical root causes, including flaws in Log4J’s message lookup functionality, which enabled attackers to exploit untrusted inputs. The presenters emphasize the rapid response from the Apache community, which released patches and mitigations under intense pressure, highlighting the challenges of maintaining widely-used open-source libraries.

The session provides a sobering look at the incident’s widespread effects, from internal projects to global enterprises. By sharing a detailed post-mortem, the trio illustrates how Log4Shell exposed vulnerabilities in dependency management, urging organizations to prioritize robust software supply chain practices.

Apache’s Security Practices and Challenges

The presenters delve into the Apache Foundation’s approach to managing Common Vulnerabilities and Exposures (CVEs). They explain that the foundation relies on a small, dedicated group of volunteer committers—often fewer than 15 per project—making comprehensive code reviews challenging. Emmanuel, Jean-Baptiste, and Hervé acknowledge that limited resources and the sheer volume of contributions can create gaps, as seen in Log4Shell. However, they defend the open-source model, noting its transparency and community-driven ethos as strengths that enable rapid response to issues.

They highlight systemic challenges, such as the difficulty of auditing complex codebases and the reliance on volunteer efforts. The trio calls for greater community participation, emphasizing that open-source projects like Apache thrive on collective contributions, which can enhance security and resilience.

Solutions and Future Prevention

To prevent future vulnerabilities, Emmanuel, Jean-Baptiste, and Hervé propose several strategies. They advocate for enhanced code review processes, including automated tools and mandatory audits, to catch issues early. They also discuss the potential for increased funding to support open-source maintenance, noting that financial backing could enable more robust security practices. However, they stress that money alone is insufficient; better organizational structures and community engagement are equally critical.

The presenters highlight emerging regulations, such as those in the U.S. and Europe, that hold software vendors accountable for their dependencies. These laws underscore the need for organizations to actively manage their open-source components, fostering a collaborative relationship between developers and users to ensure security.

Engaging the Community

In their closing remarks, the trio urges developers to become active contributors to open-source projects like Apache. They emphasize that even small contributions, such as reporting issues or participating in code reviews, can significantly enhance project security. Jean-Baptiste, Emmanuel, and Hervé invite attendees to engage with the Apache community, noting that projects like Log4J rely on collective effort to thrive. Their call to action underscores the shared responsibility of securing the open-source ecosystem, making it a compelling invitation for developers to get involved.

Links:

• Apache Software Foundation website

Hashtags: #Log4Shell #OpenSource #Cybersecurity #DevoxxFR2022 #EmmanuelLécharny #JeanBaptisteOnofré #HervéBoutemy #Apache

Do You Really Know JWT? Insights from Devoxx France 2022

Karim Pinchon, a backend developer at Ornikar, delivered an illuminating talk titled “Do You Really Know JWT?” (watch on YouTube). With a decade of experience across Java, PHP, and Go, Karim dives into JSON Web Tokens (JWT), a standard for secure data transfer in authentication and authorization. This session explores JWT’s structure, cryptographic foundations, vulnerabilities, and best practices, moving beyond common usage in OAuth2 and OpenID Connect.

Understanding JWT Structure and Cryptography

Karim begins by demystifying JWT, a compact, secure token for transferring JSON data, often used in HTTP headers for authentication. A JWT comprises three parts—header, payload, and signature—encoded in Base64 and concatenated with dots. The header specifies the cryptographic algorithm (e.g., HMAC, RSA), the payload contains claims (data), and the signature ensures integrity. Karim demonstrates this using jwt.io, showing how decoding reveals JSON objects.

He distinguishes token types: reference tokens (database-backed) and value tokens (self-contained, like JWT). JWT supports two forms: compact (Base64-encoded) and JSON (with additional features like multiple signatures). Karim introduces related standards under JOSE (JSON Object Signing and Encryption), including JWS (signed tokens), JWE (encrypted tokens), JWK (key management), and JWA (algorithms). Cryptographic operations like signing (for integrity) and encryption (for confidentiality) underpin JWT’s security.

Payload Claims and Use Cases

The payload is JWT’s core, divided into three claim types:

• Registered Claims: Standard fields like issuer (iss), audience (aud), expiration (exp), and token ID (jti) for validation.
• Public Claims: Defined by IANA for protocols like OpenID Connect, carrying user data (e.g., name, email) in ID tokens.
• Private Claims: Custom data agreed upon by parties, kept minimal for compactness.

Karim highlights JWT’s versatility in:

• API Authentication: Tokens in Authorization headers validate requests without database lookups.
• OAuth2: Access tokens may be JWTs, carrying authorization data.
• OpenID Connect: ID tokens propagate user identity.
• Stateless Sessions: Storing session data (e.g., e-commerce carts) client-side, enhancing scalability.

He cautions that stateless sessions require careful implementation to avoid complexity.

Security Vulnerabilities and Attacks

Karim dedicates significant time to JWT’s security risks, demonstrating attacks via a PHP library on his GitHub. Common vulnerabilities include:

• Unsecured Tokens: Setting the header’s algorithm to none bypasses signature verification, a flaw exploited in some libraries. Karim shows a test where a modified token passes validation due to this.
• RSA Public Key as Shared Key: An attacker changes the algorithm from RSA to HMAC, using the public key as a shared secret, tricking servers into validating tampered tokens.
• Brute Force: Weak secrets (e.g., “azerty”) are vulnerable to brute-force attacks.
• Encrypted Data Modification: Some encryption algorithms allow payload tampering (e.g., flipping is_admin from false to true) without breaking the cipher.
• Token Substitution: Using a token from one service (where the user is admin) on another without proper audience validation.

Karim emphasizes the JWT paradox: the header, which specifies validation details, can’t be trusted until the token is validated. He attributes these issues to developers’ reliance on unvetted libraries, not poor coding.

Best Practices for Secure JWT Usage

To mitigate risks, Karim offers practical advice:

• Protect Secrets: Use strong, rotated keys. Avoid sharing symmetric keys with external partners; prefer asymmetric keys (e.g., RSA).
• Restrict Algorithms: Servers should only accept predefined algorithms (e.g., one or two), ignoring the header’s alg field.
• Validate Claims: Check iss, aud, and exp to ensure the token’s legitimacy. Reject tokens not intended for your service.
• Use Trusted Libraries: Avoid custom implementations. Modern libraries require explicit algorithm whitelists, reducing none algorithm risks.
• Short Token Lifespans: Minimize revocation needs with short-lived tokens. Avoid external revocation lists, as they undermine JWT’s autonomy.
• Ensure Confidentiality: Since JWS payloads are Base64-encoded (readable), avoid sensitive data. Use JWE for encryption if needed, and transmit over HTTPS.

Karim also mentions alternatives like Biscuits (from Clever Cloud), PASETO, and Google’s Macaroons, which address JWT’s flaws, such as untrusted headers.

Links

• YouTube Video: Do You Really Know JWT?
• Karim Pinchon: LinkedIn, Twitter, GitHub
• Ornikar: Official Website
• JWT: Official Website

Hashtags: #DevoxxFrance #KarimPinchon #JWT #Security #Cryptography #Authentication #Authorization #OAuth2 #OpenIDConnect #JWS #JWE #JWK #Ornikar #PHP #Java

At Devoxx Poland 2022, Viktor Gamov, a dynamic developer advocate at Kong, delivered an engaging presentation on zero trust security and its integration with service mesh technologies. With a blend of humor and technical depth, Viktor demystified the complexities of securing modern microservice architectures, emphasizing a philosophy that eliminates implicit trust to bolster system resilience. His talk, rich with practical demonstrations, offered developers and architects actionable insights into implementing zero trust principles using tools like Kong’s Kuma service mesh, making a traditionally daunting topic accessible and compelling.

The Philosophy of Zero Trust

Viktor begins by challenging the conventional notion of trust, using the poignant analogy of The Lion King to illustrate its exploitable nature. Trust, he argues, is a vulnerability when relied upon for system access, as it can be manipulated by malicious actors. Zero trust, conversely, operates on the premise that no entity—human or service—should be inherently trusted. This philosophy, not a product or framework, redefines security by requiring continuous verification of identity and access. Viktor outlines four pillars critical to zero trust in microservices: identity, automation, default denial, and observability. These principles guide the secure communication between services, ensuring robust protection in distributed environments.

Identity in Microservices

In the realm of microservices, identity is paramount. Viktor likens service identification to a passport, issued by a trusted authority, which verifies legitimacy without relying on trust. Traditional security models, akin to fortified castles with IP-based firewalls, are inadequate in dynamic cloud environments where services span multiple platforms. He introduces the concept of embedding identity within cryptographic certificates, specifically using the Subject Alternative Name (SAN) in TLS to encode service identities. This approach, facilitated by service meshes like Kuma, allows for encrypted communication and automatic identity validation, reducing the burden on individual services and enhancing security across heterogeneous systems.

Automation and Service Mesh

Automation is a cornerstone of effective zero trust implementation, particularly in managing the complexity of certificate generation and rotation. Viktor demonstrates how Kuma, a CNCF sandbox project built on Envoy, automates these tasks through its control plane. By acting as a certificate authority, Kuma provisions and rotates certificates seamlessly, ensuring encrypted mutual TLS (mTLS) communication between services. This automation alleviates manual overhead, enabling developers to focus on application logic rather than security configurations. During a live demo, Viktor showcases how Kuma integrates a gateway into the mesh, enabling mTLS from browser to service, highlighting the ease of securing traffic in real-time.

Deny by Default and Observability

The principle of denying all access by default is central to zero trust, ensuring that only explicitly authorized communications occur. Viktor illustrates how Kuma’s traffic permissions allow precise control over service interactions, preventing unauthorized access. For instance, a user service can be restricted to only communicate with an invoice service, eliminating wildcard permissions that expose vulnerabilities. Additionally, observability is critical for detecting and responding to threats. By integrating with tools like Prometheus, Loki, and Grafana, Kuma provides real-time metrics, logs, and traces, enabling developers to monitor service interactions and maintain an up-to-date system overview. Viktor’s demo of a microservices application underscores how observability enhances security and operational efficiency.

Practical Implementation with Kuma

Viktor’s hands-on approach culminates in a demonstration of deploying a containerized application within a Kuma mesh. By injecting sidecar proxies, Kuma ensures encrypted communication and centralized policy management without altering application code. He highlights advanced use cases, such as leveraging Open Policy Agent (OPA) to enforce fine-grained access controls, like restricting a service to read-only HTTP GET requests. This infrastructure-level security decouples policy enforcement from application logic, offering flexibility and scalability. Viktor’s emphasis on developer-friendly tools and real-time feedback loops empowers teams to adopt zero trust practices with minimal friction, fostering a culture of security-first development.

Links:

• Kong company website
• Kuma project website

Hashtags: #ZeroTrust #ServiceMesh #Microservices #Security #Kuma #Kong #DevoxxPoland #ViktorGamov

At ScalaDays Lausanne 2019, Manohar Jonnalagedda and Jakob Odersky, researchers turned industry innovators, unveiled a Scala-powered approach to secure multi-party computation (MPC) at EPFL’s 10th anniversary conference. Their talk, moments before lunch, captivated attendees with a protocol to average salaries without revealing individual data, sparking curiosity about privacy-preserving applications. Manohar and Jakob, from Inpher, detailed a compiler transforming high-level code into secure, distributed computations, addressing real-world challenges like GDPR-compliant banking and satellite collision detection, earning applause and probing questions on security and scalability.

A Privacy-Preserving Protocol

Manohar opened with a relatable scenario: wanting to compare salaries with Jakob without disclosing personal figures. Their solution, a privacy-preserving protocol, lets three parties—Manohar, Jakob, and their CTO Dmitar—compute an average securely. Each generates three random numbers summing to zero, sharing them such that each party holds a unique view of partial sums. In Scala, this is modeled with a SecretValue type for private integers and a SharedNumber list, accessible only by the corresponding party. Each sums their shares, publishes the result, and the final sum reveals the average without exposing individual salaries. This protocol, using random shares, ensures no single party can deduce another’s data unless all communications are intercepted, balancing simplicity and security.

Secure Multi-Party Computation

Jakob explained MPC as a cryptographic subfield enabling joint function computation without revealing private inputs. The salary example used addition, but MPC supports multiplication via Beaver triplets, precomputed by a trusted dealer for efficiency. With addition and multiplication, MPC handles polynomials, enabling linear and logistic regression or exponential approximations via Taylor polynomials. Manohar highlighted Scala’s role in modeling these operations, with functions for element-wise addition and revealing sums. The protocol achieves information-theoretic security for integers, where masked values are indistinguishable, but floating-point numbers require computational security due to distribution challenges. This flexibility makes MPC suitable for complex computations, from machine learning to statistical analysis, all while preserving privacy.

Real-World Applications

MPC shines in domains where data sensitivity or legal constraints, like GDPR, restrict sharing. Manohar cited ING, a bank building credit-scoring models across European countries without moving user data across borders, complying with GDPR. Another compelling case involved satellite operators—American, Russian, or Chinese—secretly computing collision risks to avoid incidents like the 2009 Iridium-Cosmos crash, which threatened the International Space Station. Jakob emphasized that Inpher’s XOR platform, legally vetted by Baker McKenzie, ensures GDPR compliance by keeping data at its source. These use cases, from finance to defense, underscore MPC’s value in enabling secure collaboration, with Scala providing a robust, type-safe foundation for protocol implementation.

Building a Compiler for MPC

To scale MPC beyond simple embeddings, Manohar and Jakob’s team developed a compiler at Inpher, targeting a high-level language resembling Python or Scala for data scientists. This compiler transforms linear algebra-style code into low-level primitives for distributed execution across parties’ virtual machines, verified to prevent data leaks. It performs static analysis to optimize memory and communication, inferring masking parameters to minimize computational overhead. For example, multiplying masked floating-point numbers risks format explosion, so the compiler uses fixed-point representations and statistical bounds to maintain efficiency. The output, resembling assembly for MPC engines, manages memory allocation and propagates data dimensions. While currently MPC-focused, the compiler’s design could integrate other privacy techniques, offering a versatile platform for secure computation.

Links:

• Session Video
• Session Abstract
• Inpher XOR Platform
• SP DZ Protocol Reference

Hashtags: #ScalaDays2019 #Scala #Privacy #MPC

Amid the internet’s inexorable expansion, where identities intermingle in a vast virtual bazaar, nomenclature emerges not merely as label but as linchpin of legitimacy and liability. Paul Mockapetris, the visionary architect of the Domain Name System (DNS), unraveled this nexus at dotSecurity 2017, positing names as the nascent nucleus of network nativity—superseding addresses in an era of fluid federation. From USC’s Information Sciences Institute to ThreatSTOP’s chief scientific stewardship, Paul’s provenance—DNS’s 1983 inception—imbues his insights with unparalleled pedigree, transforming arcane protocols into actionable armaments against cyber malfeasance.

Paul’s preamble pulsed with principles: network’s nectar in connectivity’s cornucopia, generative genius in repurposing relics—DNS’s domain, a namespace nexus granting granular governance amid global glue. Scaling’s saga: hierarchical hierarchies, root’s realm radiating to TLDs’ tributaries—federation’s finesse in delegation’s dance, authorities autonomous yet amalgamated. Security’s shadow: names’ nobility invites nefariousness—phishing’s phalanx, malware’s masquerade, DDoS’s deluge. Paul parsed perils: DNS amplification’s acoustic assault (amplifiers unwitting, queries quartered to quintupled payloads), cache’s corruption (poison’s payload, TTL’s tyranny), BGP’s brittleness (routes rerouted, traffic tunneled).

Countermeasures crystallized: DNSSEC’s digital deeds—RRSIG’s ratification, DS’s delegation—yet adoption’s anemia (1% in 2017) attenuates. Paul’s panacea: name-based bulwarks—reputation’s rubric (Sender Policy Framework’s sender scrutiny, Domain-based Message Authentication’s dominion), filtering’s firewall (blacklists’ ban, whitelists’ welcome). ThreatSTOP’s tapestry: DNS as sentinel, policies personalized—user’s umbrage over ISP’s imposition, EFF’s equivocation on censorship’s cusp. Kill chain’s kink: download’s dam, C2’s choke—malware muted mid-metamorphosis.

Paul’s prognosis: addresses’ atrophy, names’ ascendancy—chunked content’s cryptographic christening, bounties’ bounty for blemished bits. This nomenclature renaissance: security’s scaffold, internet’s integrity incarnate.

Nomenclature’s Nobility and Perils’ Palette

Paul proclaimed principles: network’s nexus, generative’s grace—DNS’s delegation, scaling’s symphony. Perils’ procession: amplification’s aria, cache’s contagion—BGP’s betrayal.

DNSSEC’s Deeds and Name’s Nativity

Signatures’ surety, adoption’s ache—reputation’s regime (SPF’s sieve, DMARC’s dominion). ThreatSTOP’s theorem: policies’ personalization, kill chain’s curtailment.

Bounties’ Beacon and Futures’ Forge

Addresses’ eclipse, chunks’ christening—bounties’ bite for blemish. Paul’s prophecy: names’ nativity, security’s scaffold.

Links:

• Paul Mockapetris on LinkedIn
• ThreatSTOP

In development’s dynamic deluge, where velocity’s vortex vanquishes venerable verities, security’s synthesis with speed spawns safer sanctums. Zane Lackey, Signal Sciences’ CTO and Etsy alumnus, shared this synthesis at dotSecurity 2017, recounting Etsy’s evolution from waterfall’s wane to DevOps’ dawn—100 deploys diurnal, security self-sufficiency’s sunrise. A sentinel schooled in scaling safeguards, Zane’s zeitgeist: shift from gatekeeper’s glower to enabler’s embrace, visibility’s vista vitalizing vigilance.

Zane’s zeitgeist zeroed on transformations: velocity’s vault (18 months to moments), infrastructure’s illusion (cloud’s churn, containers’ cadence), ownership’s osmosis (devs’ dominion over deploys). Security’s schism: outsourced obstruction to integrated impetus—feedback’s flux fostering fixes. Etsy’s ethos: blameless postmortems’ balm, chatops’ chorus—vulnerabilities vocalized via Slack’s summons, fixes’ fanfare.

Visibility’s vanguard: dashboards’ dawn, signals’ symphony—Signal Sciences’ sentry sensing surges. Feedback’s finesse: CI’s critique, pull requests’ probes—vulnerabilities voiced in vernacular. Zane’s vignette: researcher’s rapport, exploits eclipsed by ephemeral emends—positive parleys from proactive patches.

DevOps’ dividend: safety’s surge in speed’s slipstream—mortals empowered, mishaps mitigated.

Transformations’ Tide and Security’s Shift

Zane zeroed on zeal: velocity’s vault, cloud’s churn—ownership’s osmosis. Gatekeeper’s glower to enabler’s embrace.

Visibility’s Vista and Feedback’s Flux

Dashboards’ dawn, chatops’ chorus—CI’s critique, pull’s probes. Zane’s vignette: researcher’s rapport, ephemeral emends.

Links:

• Zane Lackey on LinkedIn
• Signal Sciences