Hamdaan Ali
GenAI Engineer at Intuit | GSoC Mentor @Dart Org | Founding Engineer @Boost | Author @FreeCodeCamp MonSchool
Bengaluru, India
Actions
I'm a software engineer, architect, and open-source maintainer working at the intersection of security, identity, performance, and infrastructure. I build reliable systems, contribute to developer tools, and write about authentication, access control, API security, and performance engineering.
Area of Expertise
Topics
When NO_PROXY Lies: Finding an IPv4-Mapped IPv6 Bypass in Axios
I’ll explain how I analyzed a security fix in Axios and found a bypass route via IPv4-mapped IPv6 addresses. The patch normalized hostname edge cases for NO_PROXY but relied on string comparisons, leaving a gap where hosts could be represented differently. I’ll demonstrate how this occurs, why URL normalization affects NO_PROXY matching, and how to fix it. The case study highlights patch-bypass hunting and secure coding practices. Issue fixed in Axios: CVE-2026-44492 - public on June 15, 2026.
When FFI Tests Aren't Enough: Bringing Sanitizers to Dart Native Assets
A native Dart package can pass every functional test and still be one bad pointer lifetime away from crashing a Flutter app.
I ran into this while moving package:webcrypto onto Dart native assets. Its FFI layer wraps BoringSSL pointers, transfers ownership across scopes, and relies on Dart finalizers. The crypto worked, but ordinary tests could not prove that GC pressure, failed imports, or cleanup bugs would not expose native memory errors.
Valgrind gave us an immediate safety net. ASan should have been the next CI flag, but that exposed gaps between Dart build hooks, package:test, AOT compilation, and sanitizer runtimes. Appended AOT snapshots also made Dart symbols difficult for native symbolizers to reach.
That package problem led upstream into the Dart SDK. I added a Linux CLI bundle with one shared runtime and separate AOT snapshots, added ASan, MSan, and TSan support to package:test, and added SDK integration coverage using a real hook-built native asset.
Finally, we broke the C code deliberately and verified that ASan caught the heap-buffer-overflow through the same test path.
This session follows that path from webcrypto to package:test, native fixtures, and the Dart SDK: where FFI tests stop, how Valgrind and sanitizers complement each other, why the AOT layout mattered, and how package authors can build a useful native memory-safety CI lane with commands such as `dart test -c cli -p vm-asan`.
The Missing Half of AD Sync: Removing Stale Access Without Breaking Overrides
Most identity sync jobs look fine until you ask them to remove something.
Our Keycloak federation flow pulled users from Microsoft Entra ID, mapped AD groups to application roles, and kept users up to date on a schedule. New users appeared. Existing users got refreshed. Group assignments were added. On paper, the sync was working.
Then we looked at the other side of the problem.
What happens when a user is removed from an AD group? What happens when someone leaves the organization? What happens when a user still has a manually granted application-level Admin role that should not be wiped by automation?
That is where the simple “read group, add users” model started to fall apart. The sync knew how to add access, but the removal path was either incomplete, risky, or too expensive to implement naively. We had to answer a harder question: for every synced user, what access still comes from AD, what access should be revoked, and what access must be protected because it was granted outside AD?
This talk walks through how we redesigned that part of the sync.
We will start with the failure mode: group-by-group AD sync, stale Keycloak users, and roles that drift over time. Then we will show the design we moved toward: treating each sync run as a small data pipeline. We extract group membership from Microsoft Graph, build a temporary membership view, compute the difference between “what AD says now” and “what Keycloak currently has, and apply changes back in controlled batches.
A key part of the solution is using DuckDB as an embedded analytical layer for the heavy set operations. Instead of loading every user-group relationship into application objects and hoping memory holds, we let DuckDB handle joins, deduplication, and delta queries with bounded memory and spill-to-disk support.
The security problem is just as important as the data problem. Some roles are AD-managed and should be removed when AD removes them. Other roles are granted manually through the application and should persist through the next sync. We will discuss how to draw that boundary, how to avoid deleting protected assignments, and how to make deprovisioning predictable rather than accidental.
This is a practical talk about identity sync as a data architecture problem: not just “call the directory API”, but design the remove path, make ownership explicit, and keep the sync safe when the dataset grows.
Key Takeaways:
- Why does add-only AD sync create ghost users, stale roles, and access drift?
- How to model a sync run as a data pipeline: extract from Microsoft Graph, transform membership data, and load changes into Keycloak.
- How DuckDB can help compute user/group deltas without building large in-memory maps in application code.
- How to separate AD-managed access from manually granted or protected roles.
- Practical failure cases to handle: partial Graph failures, orphan users, batching, retries, and safe de-provisioning.
Intended Audience:
Intermediate backend, platform, IAM, and infrastructure engineers.
This talk is useful for anyone working on identity sync, directory integration, user provisioning, access control, or large relationship-heavy data updates where correctness matters as much as performance.
Technologies Used:
Microsoft Entra ID / Azure AD
Microsoft Graph API
Keycloak User Federation
DuckDB
Java
From Flutter Plugin to Native Asset: Shipping webcrypto.dart for Dart, Flutter, and Six Platforms
package:webcrypto started life with packaging assumptions that fit Flutter better than Dart itself. With Dart build hooks stable and Flutter now recommending the package_ffi model, we re-architected webcrypto.dart into a single package that wraps window.crypto on the web and builds a BoringSSL-native backend through hooks and CMake everywhere else.
In this talk, I’ll walk through the migration captured in issue #192 and PR #236 (https://github.com/google/webcrypto.dart/pull/236): why the old package boundary stopped scaling, how hook/build.dart, code_assets, and native_toolchain_cmake changed the architecture, what broke on mobile and CI, and why follow-on work like direct bindings and artifact distribution still matters. This is not a beginner FFI session. It is a talk about package boundaries, backend strategy, and how to ship native capabilities to both Flutter and Dart users without making consumers pay the complexity tax.
I'll keep the demo's payoff simple: the same WebCrypto-style API call running in a browser, a Flutter app, and a standalone Dart CLI, each backed by different runtime and build paths. I'll keep the payoff deliberately simple in the demo: the same WebCrypto-style API call running in a browser, a Flutter app, and a standalone Dart CLI, backed by different runtime and build paths. What I really want to explore is the package architecture behind that result: where to draw package boundaries, how to choose and wire up backends, and how build hooks and native assets can support both Flutter and Dart users without making the package harder to use.
Key takeaways:
- How to recognize when a native-backed package has outgrown Flutter-plugin-shaped packaging.
- How Dart build hooks, CMake, and native assets change the boundary between package author, app developer, and build system.
- How to keep one public Dart API while routing work across browser and native backends.
- How to structure `hook/build.dart`, CMake, bindings, and asset lookup so the same package serves Flutter apps and standalone Dart consumers.
- What stayed hard after the migration: mobile packaging edge cases, CI fallout, symbol binding cleanup, and the still-open question of first-class prebuilt native asset distribution.
JavaScript Security: Defending against Prototype Pollution Attacks
Prototype pollution is a security vulnerability in JavaScript that allows malicious actors to introduce arbitrary properties into global object prototypes. This may lead to Denial of Service (DoS), Session Fixation, Security Bypass Checks, SQL and NoSQL Injections, and Remote Code execution.
In this talk, we'll first understand the JavaScript Inheritance model and how the prototype functions in JavaScript. We will then understand what Prototype Pollution is and how Prototype Pollution works with the help of a live demonstration. Finally, we will explore ways to defend our application against Prototype Pollution attacks in the same demonstration.
Flutter + Auth0 = Securely Awesome Apps
In this technical session, I will share my extensive experience in integrating Auth0 with Flutter to provide secure and reliable authentication in Flutter apps. I will demonstrate best practices, advanced authentication techniques, and tips for building scalable and secure Flutter apps that meet production standards. Attendees will also learn about Auth0's rich set of features for authentication and authorization and how it compares to other solutions. This session will help developers learn about the rich developer experience and understand how to leverage the power of Auth0 to create seamless and personalized authentication experiences for their users in production.
DevFest Hubli 2023 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top