# Cookies Published articles for Cookies. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Session revocations at scale DevFeed: [Session revocations at scale]() Original publisher: [Read original article]() Author: Llew Vallis Published: 2026-07-22T00:00:01Z Content type: article Language: en Sources: [Canva Engineering]() Topics: [sessions](), [Cookies](), [Authorization](), [Caching](), [MySQL](), [scaling](), [gateway](), [Redis](), [reliability]() Tags: [backend](), [caching](), [cookies](), [gateway](), [mysql](), [permissions](), [redis](), [reliability](), [scaling](), [security](), [sessions]() ### AI overview Canva describes how it manages session revocations for hundreds of millions of users. The system keeps revocations in memory for fast gateway checks, while MySQL handles refresh-time lookups; the article explains how loading the cache during deployments created database load and discusses evaluating Redis as a caching solution. ### Source excerpt How Canva keeps hundreds of millions of user sessions fast and secure ## Building a Self-Hosted Analytics Dashboard in One Session DevFeed: [Building a Self-Hosted Analytics Dashboard in One Session]() Original publisher: [Read original article]() Published: 2026-03-25T00:00:00Z Content type: tutorial Language: en Sources: [Alex Korbonits]() Topics: [dashboards](), [Self-hosted](), [Netlify](), [Supabase](), [Astro](), [Serverless](), [Dark Mode]() Tags: [analytics](), [building](), [cookies](), [dark-mode](), [dashboard](), [google-analytics](), [netlify](), [self-hosted]() ### AI overview A tutorial describing how to build a self-hosted analytics dashboard without Google Analytics or third-party tracking scripts. The implementation uses a beacon, a Netlify serverless function, Supabase, build-time rendering, and an authenticated analytics page. ### Source excerpt No Google Analytics, no third-party scripts, no cookies. Just a Netlify function, Supabase, and a Chart.js dashboard I actually own. ## Using cookies to hack into a tech college's admission system DevFeed: [Using cookies to hack into a tech college's admission system]() Original publisher: [Read original article]() Author: Eaton Published: 2026-03-09T13:41:25Z Content type: article Language: en Sources: [Eaton Works Feed]() Topics: [Security](), [Web app](), [API](), [Authentication](), [Vulnerabilities](), [JavaScript](), [HTTP]() Tags: [api](), [authentication](), [cookies](), [data](), [http](), [india](), [javascript](), [security](), [vulnerability](), [web](), [web-app]() ### AI overview The article describes how missing authentication on SKCET's admission APIs allowed manual cookie manipulation to bypass login and impersonate an admission officer. By discovering an officer GUID through student searches, the author accessed reports containing sensitive information about 4,110 students, including contact, address, Aadhaar, medical, demographic, academic, and income data. ### Source excerpt The Sri Krishna College of Engineering and Technology (SKCET) in India made elementary mistakes in web app security. ## 15 Best SaaS Affiliate Programs 2026: Up to 50% Recurring Commissions DevFeed: [15 Best SaaS Affiliate Programs 2026: Up to 50% Recurring Commissions]() Original publisher: [Read original article]() Author: Joshua D'Costa Published: 2025-12-02T00:00:00Z Content type: article Language: en Sources: [Dodo Payments Blog]() Topics: [Software as a service]() Tags: [2026](), [b2b](), [browser](), [cookies](), [growth](), [influencers](), [marketing](), [partners](), [saas](), [sales]() ### AI overview This article explains affiliate marketing and how affiliate links use unique IDs, cookies, and tracking to attribute purchases and commissions. It compares SaaS affiliate programs by commission rates, cookie length, payout terms, and acceptance requirements. ### Source excerpt Top-paying SaaS affiliate programs ranked by commission rate (10%-50% recurring), cookie length, payout terms, and ease of acceptance. Includes one-time and lifetime tiers. ## Top 10 web hacking techniques of 2024 DevFeed: [Top 10 web hacking techniques of 2024]() Original publisher: [Read original article]() Author: James Kettle Published: 2025-02-04T15:01:48Z Content type: article Language: en Sources: [PortSwigger Research]() Topics: [Hacking](), [Application Security](), [Security](), [web applications](), [OAuth](), [Cache](), [account takeover](), [LocalStorage](), [JavaScript]() Tags: [2025](), [account-takeover](), [cache](), [chatgpt](), [cookies](), [hacking](), [oauth](), [research](), [security](), [techniques](), [web](), [xss]() ### AI overview This annual community-powered review identifies notable web security research and hacking techniques from 2024. The supplied excerpts discuss OAuth flow hijacking through Cookie Tossing, risks involving cookies and JavaScript's Same-Origin Policy, and a ChatGPT account takeover using inconsistent decoding, path traversal, and Web Cache Deception. ### Source excerpt Welcome to the Top 10 Web Hacking Techniques of 2024, the 18th edition of our annual community-powered effort to identify the most innovative must-read web security research published in the last year ## Bypassing WAFs with the phantom $Version cookie DevFeed: [Bypassing WAFs with the phantom $Version cookie]() Original publisher: [Read original article]() Author: Zakhar Fedotkin Published: 2024-12-04T15:03:35Z Content type: article Language: en Sources: [PortSwigger Research]() Topics: [Parsing](), [HTTP](), [Vulnerabilities](), [Cross-origin resource sharing (CORS)](), [Spring Boot](), [Python](), [Flask](), [Django]() Tags: [cookies](), [django](), [flask](), [http](), [parsing](), [python](), [security](), [spring-boot](), [vulnerabilities]() ### AI overview This article explains how differences between HTTP cookie parsers can be exploited to bypass web application firewalls. It examines legacy cookie features such as the phantom $Version attribute, quoted values, and octal escape sequences, with examples from Spring Boot, Apache Tomcat, and Python frameworks including Flask and Django. ### Source excerpt HTTP cookies often control critical website features, but their long and convoluted history exposes them to parser discrepancy vulnerabilities. In this post, I'll explore some dangerous, lesser-known ## Third-Party Cookies, Single Sign-On, and the Limits of Browser Privacy Interventions DevFeed: [Third-Party Cookies, Single Sign-On, and the Limits of Browser Privacy Interventions]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-07-30T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Cookies](), [Web](), [Single sign-on (SSO)](), [W3C](), [browsers](), [Google]() Tags: [browsers](), [cookies](), [google](), [identity](), [privacy](), [sso](), [w3c](), [web](), [webdev]() ### AI overview This commentary critiques the W3C Technical Architecture Group's response to Google's decision not to imminently remove third-party cookies. It argues that the response underplays both the limited benefits of cookie removal and the unresolved effects on Single Sign-On, sign-in flows, advertising, and user tracking. ### Source excerpt The W3C Technical Architecture Group1 is out with a blog post and an updated Finding regarding Google's recent announcement that it will not be imminently removing third-party cookies. The current TAG members are competent technologists who have a long history of nuanced advice that looks past the shouting to get at the technical bedrock of complex situations. The TAG also plays a uniquely helpful role in boiling down the guidance it issues into actionable principles that developers can easily follow. All of which makes these pronouncements seem like weak tea. To grok why, we need to walk through the threat model, look at the technology options, and try to understand the limits of technical interventions. Contents Unmasking The Problem Fire And Movement Finding A Way Forward But before that, I should stipulate my personal position on third-party cookies: they aren't great! They should be removed from browsers when replacements are good and ready, and Google's climbdown isn't helpful. That said, we have seen nothing of the hinted-at alternatives, so the jury's out on what the impact will be in practice.2 So why am I dissapointed in the TAG, given that my position is essentially what they wrote? Because it failed to acknowledge the limited and contingent upside of removing third-party cookies, or the thorny issues we're left with after they're gone. Unmasking The Problem So, what do third-party cookies do? And how do they relate to the privacy theat model? Like a lot of web technology, third-party cookies have both positive and negative uses. Owing to a historcal lack of platform-level identity APIs, they form the backbone of nearly every large Single Sign-On (SSO) system. Thankfully, replacements have been developed and are being iterated on. Unfortunately, some browsers have unilaterally removed them without developing such replacements, disrupting sign-in flows across the web, harming users and pushing businesses toward native mobile apps. That's bad, as native app ## Why Nonprofits and Public Organizations Should Reconsider Website Cookies and Tracking DevFeed: [Why Nonprofits and Public Organizations Should Reconsider Website Cookies and Tracking]() Original publisher: [Read original article]() Published: 2024-05-06T19:07:14Z Content type: opinion Language: nl Sources: [Bert Hubert's writings]() Topics: [Cookies](), [Google Analytics](), [Internet]() Tags: [analytics](), [cookies](), [google](), [google-analytics](), [privacy](), [surveillance](), [trackers](), [tracking]() ### AI overview The article argues that nonprofits and public organizations often use cookies, trackers, and Google Analytics without clear evidence that the resulting statistics inform real decisions. It questions the privacy and practical value of this tracking. ### Source excerpt We leven in rare tijden. Cookies en tracking zijn overal op internet. We worden overal gevolgd, iedere klik wordt bijgehouden. Tools als Google Analytics zijn hierbij een Faustiaanse deal: De analytics vertellen jou dingen over je gebruikers, en in ruil vertel jij Google wat diezelfde gebruikers op jouw site doen. Vreemd genoeg hebben bergen non-profit en (overheids)organisaties met goede bedoelingen ook al die cookies en trackers aanstaan op hun sites. Zo doen ze vrolijk mee aan "surveillance capitalism", ook al hoeven ze niet te leven van advertenties. ## Trifecta: Open-source software for self-hosted image sharing DevFeed: [Trifecta: Open-source software for self-hosted image sharing]() Original publisher: [Read original article]() Published: 2024-01-18T09:22:53Z Content type: article Language: en Sources: [Bert Hubert's writings]() Topics: [Software](), [Open Source](), [Image](), [Databases](), [JavaScript](), [C++](), [SQLite](), [Back end](), [Front end](), [servers](), [Docker]() Tags: [backend](), [c-plus-plus](), [cookies](), [database](), [docker](), [frontend](), [images](), [javascript](), [open-source](), [security](), [software](), [trackers]() ### AI overview Trifecta is a self-contained, open-source image-sharing application designed for company, group, or personal use. It includes user and session management, multi-image posts, optional captions and titles, public or time-limited sharing, passwordless login, password recovery, and deployment options including Docker, binaries, and package files. ### Source excerpt Trifecta is actual stand-alone software that you can use to paste and drag images to, for easy sharing. It has pained me for years that I had to use imgur for this purpose. Not only does imgur install lots of cookies and trackers on my browser, I also then force these onto the people that visit the images that I share. I checked out some existing solutions you could download, but I worry about their security. ## How to protect Node.js apps from CSRF attacks DevFeed: [How to protect Node.js apps from CSRF attacks]() Original publisher: [Read original article]() Author: Victor Ikechukwu Published: 2023-10-17T05:00:00Z Content type: tutorial Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Node.js](), [Vulnerabilities](), [Security](), [web applications](), [browser]() Tags: [application-security](), [attacks](), [blog](), [code-security](), [contentlab](), [cookies](), [how-to](), [javascript](), [node](), [node-js](), [security](), [snyk-code](), [snyk-open-source](), [vulnerability](), [web-applications]() ### AI overview This tutorial explains cross-site request forgery (CSRF) attacks against Node.js applications. It describes how attackers exploit trust in authenticated browser sessions, session IDs, and cookies to trigger unauthorized actions, then introduces practical protection methods, testing approaches, code examples, and security best practices. ### Source excerpt Victor Ikechukwu October 17, 2023 A cross-site request forgery attack (CSRF) attack is a security vulnerability capitalizing on trust between a web browser and a legitimate website. Crafty attackers manipulate browsers into executing malicious actions on websites where users authenticate themselves and log in. Often, these attacks start when users click a link attached to a deceptive email or land on a compromised website, unaware of the logic executing in the background. ## What Are JWTs? DevFeed: [What Are JWTs?]() Original publisher: [Read original article]() Author: info@goteleport.com (Victor Elezua) Published: 2022-09-27T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [JSON Web Tokens](), [Authorization](), [distributed-systems](), [Cookies](), [JSON]() Tags: [authorization](), [cookies](), [distributed](), [ecdsa](), [http](), [implementation](), [json](), [jwt](), [microservices](), [private-key]() ### AI overview This tutorial explains JSON Web Tokens (JWTs), including their definition, compact self-contained structure, digital signing methods, authorization use, stateless session management, benefits, risks, and common implementation mistakes. It also contrasts JWT-based sessions with cookies in distributed systems and microservices. ### Source excerpt In this blog post, we'll deep-dive into JSON web tokens (JWTs), how JWTs work and how to implement them securely. ## Cookie for a Thought - How to Manage HTTP Sessions DevFeed: [Cookie for a Thought - How to Manage HTTP Sessions]() Original publisher: [Read original article]() Author: sakshyam.shah@goteleport.com (Sakshyam Shah) Published: 2022-09-08T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [HTTP](), [Cookies](), [web applications](), [Access Control](), [Authentication](), [Security](), [TLS (Transport Layer Security)](), [Persistence]() Tags: [access-control](), [authentication](), [best-practices](), [browser](), [cookies](), [cryptographic](), [generate](), [hashing](), [how-to](), [http](), [identifier](), [persistence](), [protection](), [random](), [security](), [tls](), [token](), [web-applications]() ### AI overview This article explains how HTTP sessions use cookies to persist session state and support identity-based access control. It recommends protecting session IDs against guessing, replay, and theft, including the use of cryptographically secure random values and TLS. ### Source excerpt Exploring techniques and best practices to manage HTTP sessions. ## How Artsy Preserved Cookie Preferences Beyond Safari's 7-Day Limit DevFeed: [How Artsy Preserved Cookie Preferences Beyond Safari's 7-Day Limit]() Original publisher: [Read original article]() Published: 2022-08-23T00:00:00Z Content type: tutorial Language: en Sources: [Artsy]() Topics: [browser](), [WebKit](), [User experience (UX)](), [client]() Tags: [apple](), [browser](), [ccpa](), [cookies](), [gdpr](), [privacy](), [safari](), [server](), [ux](), [wwdc]() ### AI overview This article explains how Artsy addressed Safari's seven-day limit on client-side cookies, which caused cookie-consent preferences to be repeatedly requested. It describes replacing the client-side cookie with a same-domain, secure, server-side cookie so the preferences persist beyond seven days. ### Source excerpt Amongst the many, many things that organizations have to contend with around cookie consent laws is Apple's very own browser, Safari. Did you know that Safari will only retain a client-side cookie for 7 days? This is in support of Apple's Intelligent Tracking Prevention (ITP) feature, designed to protect a user's privacy. These privacy efforts are great but, in hand with laws like GDPR and CCPA, their rollout often creates a UX nightmare for users without some extra care. Here at Artsy, we've landed on a way to make things slightly less bad and want to share our approach. Scenario: Imagine that as a EU resident you visit artsy.net for the first time. A banner appears asking you to Accept or Deny tracking cookies from our site. You don't like tracking cookies, so you click the "Deny" button and the banner disappears. All good, right? Nope! You visit Artsy a week later and again, a banner appears asking you to choose your preferences. This happens again and again until you switch browsers and realize that what you were experiencing was Apple's ITP feature in action. After choosing your preferences, the cookie we use to store them is erased after 7 days, necessitating another interaction. We thrashed around in this vicious cycle for months until we found a simple, elegant solution thanks to a WebKit engineer's prompt (during Apple's open lab calls at WWDC - which you too can schedule!) She mentioned that the 7-day cookie limitation only applies to client-side cookies and that same-domain, secure, server-side cookies are not limited to these constraints. This got us thinking. Our third-party cookie consent management service sets a client-side cookie, not a server-side cookie. Could we perhaps overwrite the client-side cookie with a server-side cookie of the same name and trick Safari into persisting the user preferences beyond the 7-day limit? We gave it a try and... Yes. We. Can! And this means that you can too (and it's also real easy to implement). First, define an AP ## Cross-Origin Web Sessions DevFeed: [Cross-Origin Web Sessions]() Original publisher: [Read original article]() Author: info@goteleport.com (Russell Jones) Published: 2021-05-04T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Web](), [web applications](), [Cookies](), [Security](), [XSS]() Tags: [cookies](), [http](), [request](), [security](), [vulnerabilities](), [web](), [web-applications](), [xss]() ### AI overview This article examines mechanisms for securely transferring user sessions between web applications hosted on different domains. It explains browser cookies, session tokens, domain limitations, and query parameters as one approach for cross-origin session sharing. ### Source excerpt Russell examines the available mechanisms for securely transferring user sessions across different web applications running at different domains. ## Web Authentication at Headspace using Auth0 DevFeed: [Web Authentication at Headspace using Auth0]() Original publisher: [Read original article]() Author: Headspace Published: 2021-04-26T20:43:56Z Content type: tutorial Language: en Sources: [Stories by Headspace on Medium]() Topics: [Authentication](), [Auth0](), [Web](), [Cookies](), [browser]() Tags: [auth0](), [authentication](), [browser](), [cookies](), [login](), [password](), [server](), [web](), [web-authentication]() ### AI overview This article explains modern web authentication using usernames, passwords, session tokens, and browser cookies. It describes Headspace's authentication requirements across web, backend, iOS, and Android applications and explains why the company chose Auth0 as its authentication provider. ### Source excerpt Author: Jesse Bond, Senior Software Engineer, Web Introduction: How does modern authentication work? Authentication allows users to securely log into a system and verify that they are who they say they are in subsequent requests. On today's web, this usually involves creating an account using a combination of username and password. Let's start with a quick refresher on how modern web authentication works. The first step is always a user submitting their login credentials into a form. Once the form is submitted, the server will determine whether or not the username and password match that of a previously registered user. If they do match, the server will return what is known as a session token. A session token is a unique identifier that authenticates requests as coming from the same user that just logged in. It's important to note that session tokens usually are temporary and have an expiration, which is determined by the server. Now that the user has a session token, each request will need to submit the session token to ensure authentication. It might sound tedious to have to submit the session token on each request, but have no fear, the cookie is here! Cookies are small bits of information that the browser stores for a domain. Cookies are also automatically submitted when a request is sent by the browser. Does this sound like a great way to handle the session token or what? Correct! Session tokens are almost always stored in a browser cookie to make authenticating requests a breeze. Authentication requirements Headspace has a large number of Single Page Apps, backend services, websites, and iOS and Android applications. We needed a robust solution for authentication that met the following requirements: Multiple platform and language support Scalable to millions of users Reliable with high uptime Ability to separate our users into different groups with varying permissions (i.e., admins vs. standard users) Ability to restrict user access to certain applications. Fo ## CSRF Attacks: Examples and Mitigations DevFeed: [CSRF Attacks: Examples and Mitigations]() Original publisher: [Read original article]() Author: info@goteleport.com (Russell Jones) Published: 2021-03-25T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Exploit](), [web applications](), [browser](), [Cookies](), [HTML](), [HTTP](), [account takeover](), [Code]() Tags: [account-takeover](), [browser](), [code](), [cookies](), [exploit](), [html](), [http](), [xss]() ### AI overview This tutorial explains how Cross-Site Request Forgery (CSRF) attacks use browsers, HTML elements, cookies, and ambient credentials to submit requests as a logged-in user. It presents examples of state-changing requests and discusses their security impact and mitigations. ### Source excerpt Understanding Cross-Site Request Forgery (CSRF) and its Mitigations. ## Preventing XSS Attacks DevFeed: [Preventing XSS Attacks]() Original publisher: [Read original article]() Author: info@goteleport.com (Russell Jones) Published: 2021-02-23T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [XSS](), [Security](), [browser](), [Document Object Model (DOM)](), [JavaScript](), [API](), [Cookies](), [HTML]() Tags: [attacks](), [browser](), [code](), [cookies](), [html](), [javascript](), [security](), [xss]() ### AI overview This article explains cross-site scripting (XSS), how browser security mechanisms such as the Same-Origin policy, the DOM, JavaScript, and cookies shape web isolation, and why dynamically generated sites that mix code and user-controlled data are difficult to secure. It introduces XSS attack examples and mitigation concepts. ### Source excerpt Understanding Cross-Site Scripting (XSS) and Its Mitigations. ## Security Release: Laravel 6.18.29, 7.22.2 DevFeed: [Security Release: Laravel 6.18.29, 7.22.2]() Original publisher: [Read original article]() Author: Taylor Otwell Published: 2020-07-27T13:48:00Z Content type: release Language: en Sources: [Laravel Blog]() Topics: [Laravel](), [Security](), [releases]() Tags: [compatibility](), [cookies](), [laravel](), [release](), [releases](), [security](), [upgrade]() ### AI overview Laravel released security patches for versions 6.x and 7.x as Laravel 6.18.29 and 7.22.2. Users are encouraged to upgrade promptly; doing so invalidates existing application cookies and requires users to authenticate again. Passport 9.3.2 was also released for compatibility. ### Source excerpt Today we have released a security patch for Laravel versions 6.x and 7.x. These releases have been released as Laravel 6.18.29 and 7.22.2. All Laravel users are encouraged to upgrade to these versions... ## Gookies : A Chrome cookie dumper DevFeed: [Gookies : A Chrome cookie dumper]() Original publisher: [Read original article]() Author: CCob Published: 2020-02-21T17:56:12Z Content type: article Language: en Sources: [Ethical Chaos]() Topics: [Chrome](), [Encryption](), [Go Language](), [JSON](), [cURL](), [Windows](), [Command-line interface](), [GitHub]() Tags: [browsers](), [chrome](), [command-line](), [cookies](), [curl](), [decrypt](), [dump](), [encryption](), [github](), [go](), [golang](), [json](), [windows]() ### AI overview The article introduces Gookies, a Go-based tool that decrypts and dumps Chrome cookies. It supports multiple Chrome profiles, domain filtering, JSON output for cookie-manager import, and canonicalized cookie headers for command-line tools such as curl. The article states that Chrome 80 and later use a different cookie encryption scheme from version 79 and earlier, and that the tool currently supports Windows. ### Source excerpt A Chrome cookie decryptor and dumping tool The post Gookies : A Chrome cookie dumper appeared first on Ethical Chaos. ## Overview of Inter-Service Authentication Schemes DevFeed: [Overview of Inter-Service Authentication Schemes]() Original publisher: [Read original article]() Published: 2018-06-12T20:27:00Z Content type: article Language: en Sources: [Latacora]() Topics: [Authentication](), [Authorization](), [Security](), [servers](), [passwords](), [OAuth](), [saml](), [API keys](), [Cookies](), [client](), [Randomizer](), [VPC]() Tags: [api-keys](), [authentication](), [authorization](), [cookies](), [oauth](), [password](), [random](), [saml](), [security](), [server](), [vpc]() ### AI overview This article surveys server-to-server authentication and authorization schemes for systems composed of multiple services. It discusses options including bearer tokens, passwords, cookies, API keys, OAuth, and SAML, and notes risks such as token capture or logging. ### Source excerpt Modern applications tend to be composed from relationships between smaller applications. Secure modern applications thus need a way to express and enforce security policies that span multiple services. This is the "server-to-server" (S2S) authentication and authorization problem (for simplicity, I'll mash both concepts into the term "auth" for most of this post). Designers today have a lot of options for S2S auth, but there isn't much clarity about what the options are or why you'd select any of them. Bad decisions sometimes result. What follows is a stab at clearing the question up. ## Programmatically Liquidating a Steam Inventory DevFeed: [Programmatically Liquidating a Steam Inventory]() Original publisher: [Read original article]() Published: 2018-05-23T00:00:00Z Content type: tutorial Language: en Sources: [Adam Bard]() Topics: [Script](), [Authentication](), [Cookies](), [GitHub](), [API]() Tags: [authentication](), [code](), [cookies](), [github](), [script]() ### AI overview The article documents a script that automates selling items from a Steam inventory. It describes the authentication flow, inventory and item requests, price checks, sales process, and use of persistent cookies because Steam does not provide a publicly documented API for this task. ### Source excerpt I don't know about you, but every so often my Steam Inventory gets a bit out of control. I have no use for Don't Starve trading cards, but it's not really worth my time to individually sell each item for a few cents. However, what is worth my time, apparently, is creating a script to do it for me. This turned out to be quite a winding road, which I've documented here. ## Security update: Heartbleed vulnerability in OpenSSL DevFeed: [Security update: Heartbleed vulnerability in OpenSSL]() Original publisher: [Read original article]() Published: 2014-04-11T00:00:00Z Content type: news Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Security](), [Vulnerabilities](), [Exploit](), [Authentication](), [Linux](), [OAuth](), [passwords](), [Unix](), [API]() Tags: [announcements](), [api](), [authentication](), [certificates](), [cookies](), [cve](), [linux](), [maintainers](), [oauth](), [openssl](), [passwords](), [security](), [ssl](), [tokens](), [update](), [vulnerability]() ### AI overview The article explains the Heartbleed vulnerability in OpenSSL, identified as CVE-2014-0160, which could allow remote attackers to read sensitive data from process memory. SoundCloud describes its rapid patching, coordination with service providers, rotation of SSL certificates and keys, expiration of authentication tokens, and recommendation that users change passwords. It also notes that Perfect Forward Secrecy reduced the potential impact of stolen private keys and previously encrypted traffic. ### Source excerpt On Monday, April 7th, 2014, a major security vulnerability in OpenSSL was made public. The vulnerability was filed as CVE-2014-0160 and... ## XSS Protection: Who Is Responsible? DevFeed: [XSS Protection: Who Is Responsible?]() Original publisher: [Read original article]() Author: mick Published: 2011-04-08T07:09:39Z Content type: opinion Language: en Sources: [Finn.no]() Topics: [XSS](), [Security](), [Front end](), [Back end](), [Databases](), [web applications]() Tags: [backend](), [cms](), [cookies](), [databases](), [front-end](), [legacy](), [security](), [xss]() ### AI overview The article examines whether XSS protection in multi-tier applications should belong to a dedicated security team or be shared across developers. It contrasts new applications, where input may be cleaned before storage, with legacy applications whose existing backend data can require extensive front-end protection, and illustrates the issue with an advertisement service and view template. ### Source excerpt In a multi-tier application who can be responsible for XSS protection? Must security belong to a dedicated team...or can it be a shared responsibility? Today XSS protection is typically tackled by front end developers. Let's challenge the status quo. New Applications vs Legacy Applications For protection against Stored XSS many applications have the luxury of ensuring any text input from the user, or from a CMS system, is made clean and safe before being written to database. Given a clean database the only XSS protection required is around request values, for example values from url parameters, cookies, and form data. But some applications, especially legacy applications, are in a different boat. Databases typically have lots of existing data in many different formats and tables so it's often no longer feasible to focus on protecting data on its way into the system. In this situation it is the front end developers that pay the price for the poor quality of backend data and are are left to protect everything. This often results in a napalm-the-whole-forest style of xss protection where every single variable written out in the front end templates goes through some equivalent of This makes sense but... if you don't have control is your only option to be so paranoid? A Messed up World To illustrate the problem let's create a simple example by defining the following service interface AdvertisementService{ Advertisement getAdvertisement(long id); } interface Advertisement{ /** returns plain text title */ String getTitle(); /** return description, which may contain html if isHtmlEnabled() returns true */ String getDescription(); /** indicates the description is html */ boolean isDescriptionHtml(); } The web application, having already fetched an advertisement in the control tier, somewhere would have a view template looking something like

) Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2011-02-10T01:34:00Z Content type: article Language: en Sources: [Mark Seaborn]() Topics: [Chrome](), [browser](), [vulnerability](), [Exploit](), [HTML]() Tags: [browser](), [chrome](), [cookies](), [exploit](), [html](), [sandbox]() ### AI overview The article examines how a Chrome renderer-process vulnerability could allow a malicious site to access login cookies from another site through the interaction of cookies and framed pages. It explains that Chrome's sandbox offers limited cross-site protection in this scenario and discusses mitigation through separate browser profiles or avoiding cookies. ### Source excerpt Although Chrome's sandbox does not protect one web site from another in general, it can provide such protection in some cases. Those cases are ones in which HTTP cookies are either reduced in scope or not used at all. One lesson we could draw from this is that cookies reduce the usefulness of Chrome's sandbox. The scenario we are exploring supposes that there is a vulnerability in Chrome's renderer process, and that the vulnerability lets a malicious site take control of the renderer process. This means that all the restrictions that are normally enforced on the malicious site by the renderer process are stripped away, and all we are left with are the restrictions enforced on the renderer process by the Chrome browser process and the Chrome sandbox. In my previous blog post, I explained how an attacker site, evil.com, that manages to exploit the renderer process could steal the login cookies from another site, mail.com, and so gain access to the user's e-mail. The attack is made possible by the combination of two features: cookies frames Chrome currently runs a framed page in the same renderer process as the parent page. HTML standards allow framed pages to access cookies, so the browser process has to give the renderer process access to the cookies for both pages. Because this problem arises from the interaction of these features, one site is not always vulnerable to other sites. There should be a couple of ways that users and sites can mitigate the problem, without changing Chrome. Firstly, the user can change how cookies are scoped within the browser by setting up multiple profiles. Secondly, a site can skirt around the problem by not using cookies at all. We discuss these possibilities below. Use multiple profiles: As a user, you can create multiple browser profiles, and access mail.com and evil.com in separate profiles. Chrome does not make this very easy at the moment. It provides a command line option (--user-data-dir) for creating more profiles, but this fea