Pulse Security is a specialist information security consultancy.
We're here to help your business stay protected from adversaries.
We specialise in finding vulnerabilities and ensuring your systems are operating safely. Find your vulnerabilities before your adversaries.
Our focus is a collaborative and research-based approach to truly understand your vulnerabilities.
We're focused on offensive security, and our internal research program is dedicated to advancing the state-of-the-art.
All engagements follow our comprehensive technical methodologies and quality assurance process.
Our specialist offensive testing services include an extensive range of penetration testing capabilities at the application, network, and physical level.
Complementing our Penetration Testing we also perform network architecture and application review services. Helping your business achieve best practice design and secure-by-default approaches to your infrastructure.
For when things go wrong, our experienced and qualified team will help with getting you back on track.
I recently came across some interesting behavior with .NET’s Path.Combine in a web application’s file upload functionality. Despite solid efforts by the development team to prevent hacker path traversal shenanigans (by blocking the usual dangerous characters), the application was still vulnerable due to the way Path.Combine treats certain input parameters and NTFS filesystem internals.
You’ve received a penetration test or security review report. The summaries are read, the report read-out meeting has happened, and now the hard part begins! This article discusses what to do after you receive your report. We’ll talk about the process from reproducing findings and implementing fixes, through to engaging confirmation testing efficiently. Getting familiar with this process can have some sweet additional benefits, like implicit security upskilling!
Intercepting proxies are something web application penetration testers, performance engineers and developers are likely fairly familiar with. Ever notice how a bunch of that functionality already exists in the browser’s DevTools, though? This article is going to show you how to implement an intercepting proxy by connecting to the browser over CDP (Chrome DevTools Protocol), eliminating the need for HTTP CONNECT, CA certificates, and TLS interception altogether.
How can we help?
+64 4 889 4756
info at pulsesecurity.co.nz