<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>mishraJi</title>
    <link>https://blog.mishraji.org/</link>
    <description>Recent content on mishraJi</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 09 Mar 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.mishraji.org/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Part 2: Cloudflare Zero Trust - TLS Inspection</title>
      <link>https://blog.mishraji.org/posts/cloudflare-ztna-part-2/</link>
      <pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/cloudflare-ztna-part-2/</guid>
      <description>&lt;p&gt;In &lt;a href=&#34;https://blog.mishraji.org/posts/cloudflare-ztna-part-1/&#34;&gt;Part 1&lt;/a&gt;, we enabled TLS inspection to get HTTP policies working against HTTPS traffic — that&amp;rsquo;s how we blocked social media sites on port 443. We got it working, but I didn&amp;rsquo;t really explain &lt;em&gt;what&lt;/em&gt; TLS inspection is actually doing under the hood. Let&amp;rsquo;s fix that.&lt;/p&gt;&#xA;&lt;p&gt;TLS inspection is essentially a sanctioned man-in-the-middle. When your device initiates an HTTPS connection, Cloudflare Gateway intercepts it, terminates the TLS session, decrypts the traffic, inspects it, and re-encrypts before forwarding to the destination. Same thing in reverse on the way back. The Cloudflare root CA certificate we installed on the client device is what makes this work without your browser throwing certificate errors on every page.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Part 1: Cloudflare Zero Trust — Web Filtering</title>
      <link>https://blog.mishraji.org/posts/cloudflare-ztna-part-1/</link>
      <pubDate>Thu, 05 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/cloudflare-ztna-part-1/</guid>
      <description>&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;This is Part 1 of the 4-part Cloudflare Zero Trust series. In Part 0 we set up the Cloudflare One Client and tested a successful ZTNA connectivity. If you have not read that yet, I would recommend starting there before following along here.&lt;/p&gt;&#xA;&lt;p&gt;In this post we are looking at &lt;strong&gt;web filtering&lt;/strong&gt; — what it is and how to configure it using Cloudflare Zero Trust.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h3 id=&#34;what-is-web-filtering-and-why-is-it-required&#34;&gt;What is Web Filtering and Why is it Required?&lt;/h3&gt;&#xA;&lt;p&gt;Web filtering controls what a user can or cannot access on the internet. The reasons for doing it depend on who you are.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Part 0: Cloudflare One Client (Warp Client) Initial Setup </title>
      <link>https://blog.mishraji.org/posts/cloudflare-ztna-part-0/</link>
      <pubDate>Tue, 03 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/cloudflare-ztna-part-0/</guid>
      <description>&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;If you have been working in IT or security for a while, you have probably heard the term &lt;strong&gt;Zero Trust&lt;/strong&gt; thrown around a lot. But what does it actually mean in practice?&lt;/p&gt;&#xA;&lt;p&gt;Traditional network security worked on a simple assumption — if you are inside the network, you are trusted. VPNs were the go-to solution. You connect to the VPN, and suddenly you are &lt;em&gt;&amp;ldquo;on the network&amp;rdquo;&lt;/em&gt; with access to everything. The problem? Once an attacker gets in — through a compromised credential, a phishing attack, or a misconfigured endpoint — they can move laterally across the entire network with very little resistance. Trust was implicit, and that was the fundamental flaw.&lt;/p&gt;</description>
    </item>
    <item>
      <title>About Me</title>
      <link>https://blog.mishraji.org/about/</link>
      <pubDate>Wed, 01 Jan 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/about/</guid>
      <description>&lt;p&gt;Hi 👋&lt;/p&gt;&#xA;&lt;p&gt;I’m &lt;strong&gt;Navneet&lt;/strong&gt;, a techie and cloud security enthusiast!  Following are the interesting areas I have worked on and have experience with -&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Cloud &amp;amp; infrastructure Security&lt;/li&gt;&#xA;&lt;li&gt;Network Security&lt;/li&gt;&#xA;&lt;li&gt;Identity and Access Management&lt;/li&gt;&#xA;&lt;li&gt;Web Application Penetration Testing&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;This blog is a way for me to express my thoughts and learnings!&lt;/p&gt;</description>
    </item>
    <item>
      <title>Common Issues in S3 Cross-Account Access</title>
      <link>https://blog.mishraji.org/posts/s3-cross-account-access/</link>
      <pubDate>Tue, 17 Oct 2023 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/s3-cross-account-access/</guid>
      <description>&lt;figure&gt;&lt;img src=&#34;https://blog.mishraji.org/posts/s3-cross-account-access/images/image0.png&#34;&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;Originally published on &lt;a href=&#34;https://nav7neeet.medium.com/common-issues-in-s3-cross-account-access-b0fa4508a269&#34;&gt;Medium&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;Let&amp;rsquo;s explore the potential issues that can arise when setting up cross-account access to S3. Cross-account access involves a situation where a user or role in one AWS account (account1) seeks to access an S3 bucket located in another AWS account (account2). It might sound straightforward, but it&amp;rsquo;s a common scenario that can present challenges.&lt;/p&gt;&#xA;&lt;h2 id=&#34;description&#34;&gt;Description&lt;/h2&gt;&#xA;&lt;p&gt;&lt;strong&gt;Account-1&lt;/strong&gt; has IAM user &amp;ldquo;user&amp;rdquo; with &lt;a href=&#34;https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAmazonS3FullAccess&#34;&gt;AmazonS3FullAccess&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Account-2&lt;/strong&gt; has s3 bucket &amp;ldquo;my-s3-bucket-971&amp;rdquo; with 3 objects — file1, file2 and file3 along with the following resource based policy (bucket policy).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Load Balance Traffic to Private EC2 Instances</title>
      <link>https://blog.mishraji.org/posts/load-balance-traffic-to-private-ec2-instances/</link>
      <pubDate>Tue, 14 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/load-balance-traffic-to-private-ec2-instances/</guid>
      <description>&lt;figure&gt;&lt;img src=&#34;https://blog.mishraji.org/posts/load-balance-traffic-to-private-ec2-instances/images/image0.png&#34;&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;Originally published on &lt;a href=&#34;https://nav7neeet.medium.com/load-balance-traffic-to-private-ec2-instances-cb07058549fd&#34;&gt;Medium&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;Let&amp;rsquo;s take a look at how we can configure our AWS &lt;a href=&#34;https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html&#34;&gt;Application Load Balancer&lt;/a&gt; (ALB) to distribute the HTTP traffic across a set of EC2 instances present in the private subnet. As a good security measure, we don&amp;rsquo;t want our EC2 instances to be directly accessible from the internet. Hence we place them in the private subnet and assign only private IP addresses to them.&lt;/p&gt;&#xA;&lt;figure&gt;&lt;img src=&#34;https://blog.mishraji.org/posts/load-balance-traffic-to-private-ec2-instances/images/image1.png&#34;&#xA;    alt=&#34;2 EC2 instances are present in private subnets across 2 availability zones: us-east-1A and us-east-1B&#34;&gt;&lt;figcaption&gt;&#xA;      &lt;p&gt;2 EC2 instances are present in private subnets across 2 availability zones: us-east-1A and us-east-1B&lt;/p&gt;</description>
    </item>
    <item>
      <title>Defeating Encryption</title>
      <link>https://blog.mishraji.org/posts/defeating-encryption/</link>
      <pubDate>Wed, 03 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/defeating-encryption/</guid>
      <description>&lt;figure&gt;&lt;img src=&#34;https://blog.mishraji.org/posts/defeating-encryption/images/blog-image-cover.jpeg&#34;&#xA;    alt=&#34;Figure 0: Photo by Markus Spiske on Unsplash&#34;&gt;&lt;figcaption&gt;&#xA;      &lt;p&gt;Figure 0: Photo by Markus Spiske on Unsplash&lt;/p&gt;&#xA;    &lt;/figcaption&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;Originally published on &lt;a href=&#34;https://nav7neeet.medium.com/defeating-encryption-f6249a1af0b9&#34;&gt;Medium&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I came across an application where I had to validate the security fix implemented by the development team. The first assessment had findings like Vertical Privilege Escalation and Horizontal Privilege Escalation through Insecure Direct Object Reference. An attacker could simply capture a request in Burp Suite and modify &amp;lsquo;dashboardID&amp;rsquo; parameter to get read and write access to another user&amp;rsquo;s dashboard.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Maintaining NTLM Authentication Session</title>
      <link>https://blog.mishraji.org/posts/maintaining-ntlm-authentication-session/</link>
      <pubDate>Fri, 30 Jul 2021 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/maintaining-ntlm-authentication-session/</guid>
      <description>&lt;figure&gt;&lt;img src=&#34;https://blog.mishraji.org/posts/maintaining-ntlm-authentication-session/images/image0.jpeg&#34;&#xA;    alt=&#34;Photo by Arget on Unsplash&#34;&gt;&lt;figcaption&gt;&#xA;      &lt;p&gt;Photo by &lt;a href=&#34;https://unsplash.com/@arget?utm_source=unsplash&amp;amp;utm_medium=referral&amp;amp;utm_content=creditCopyText&#34;&gt;Arget&lt;/a&gt; on &lt;a href=&#34;https://unsplash.com/@arget?utm_source=unsplash&amp;amp;utm_medium=referral&amp;amp;utm_content=creditCopyText&#34;&gt;Unsplash&lt;/a&gt;&lt;/p&gt;&#xA;    &lt;/figcaption&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;Originally published on &lt;a href=&#34;https://nav7neeet.medium.com/maintaining-session-in-ntlm-authentication-3e8c604d87e9&#34;&gt;Medium&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I came across a web application that uses NTLMv2 for authentication. I logged in to the application (provided my credentials for the first time) and opened Chrome developer tool (F12) to check the requests. There was no session cookie or authorization header (Authorization: Negotiate or Authorization: Bearer) in the request. There was no other session-related information to prove that the user was logged in. I was surprised to see that the server still responded with content available only to authenticated users.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Part1: JWT Key Confusion Attack</title>
      <link>https://blog.mishraji.org/posts/jwt-key-confusion-attack-part1/</link>
      <pubDate>Thu, 11 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/jwt-key-confusion-attack-part1/</guid>
      <description>&lt;figure&gt;&lt;img src=&#34;https://blog.mishraji.org/posts/jwt-key-confusion-attack-part1/images/image0.png&#34;&#xA;    alt=&#34;Photo by Bram Naus on Unsplash&#34;&gt;&lt;figcaption&gt;&#xA;      &lt;p&gt;Photo by &lt;a href=&#34;https://unsplash.com/@bramnaus?utm_source=medium&amp;amp;utm_medium=referral&#34;&gt;Bram Naus&lt;/a&gt; on &lt;a href=&#34;https://unsplash.com/?utm_source=medium&amp;amp;utm_medium=referral&#34;&gt;Unsplash&lt;/a&gt;&lt;/p&gt;&#xA;    &lt;/figcaption&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;Originally published on &lt;a href=&#34;https://nav7neeet.medium.com/jwt-key-confusion-attack-part1-556c2db4f148&#34;&gt;Medium&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;This post deals with the theory of Key Confusion Attack. &lt;a href=&#34;https://blog.mishraji.org/posts/jwt-key-confusion-attack-part2/&#34;&gt;Part2&lt;/a&gt; deals with solving the JWT Lab by &lt;a href=&#34;https://www.sjoerdlangkemper.nl/&#34;&gt;&lt;strong&gt;Sjoerd Langkemper&lt;/strong&gt;&lt;/a&gt; to demonstrate the Key Confusion Attack.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://en.wikipedia.org/wiki/JSON_Web_Token&#34;&gt;JWT&lt;/a&gt; stands for JSON Web Token. After successful user authentication, the server sends a JWT in the response which can be used to make API calls or to access protected resources. It is typically used in the request header like&lt;/p&gt;</description>
    </item>
    <item>
      <title>Part2: JWT Key Confusion Attack</title>
      <link>https://blog.mishraji.org/posts/jwt-key-confusion-attack-part2/</link>
      <pubDate>Thu, 11 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/jwt-key-confusion-attack-part2/</guid>
      <description>&lt;figure&gt;&lt;img src=&#34;https://blog.mishraji.org/posts/jwt-key-confusion-attack-part2/images/figure-1.jpg&#34;&#xA;    alt=&#34;Photo by Bram Naus on Unsplash&#34;&gt;&lt;figcaption&gt;&#xA;      &lt;p&gt;Photo by &lt;a href=&#34;https://unsplash.com/@bramnaus?utm_source=medium&amp;amp;utm_medium=referral&#34;&gt;Bram Naus&lt;/a&gt; on &lt;a href=&#34;https://unsplash.com/?utm_source=medium&amp;amp;utm_medium=referral&#34;&gt;Unsplash&lt;/a&gt;&lt;/p&gt;&#xA;    &lt;/figcaption&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;Originally published on &lt;a href=&#34;https://nav7neeet.medium.com/jwt-key-confusion-attack-part2-e43385e658ba&#34;&gt;Medium&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;&#xA;&lt;p&gt;In &lt;a href=&#34;https://blog.mishraji.org/posts/jwt-key-confusion-attack-part1/&#34;&gt;Part1&lt;/a&gt; we discussed the Key Confusion Attack. In this post we will use a vulnerable JWT application by &lt;a href=&#34;https://www.sjoerdlangkemper.nl/&#34;&gt;Sjoerd Langkemper&lt;/a&gt; to demonstrate the attack.&lt;/p&gt;&#xA;&lt;h2 id=&#34;description&#34;&gt;Description&lt;/h2&gt;&#xA;&lt;p&gt;Install the JSON Web Token Attacker (JOSEPH) extension from the Burp Suite store (Extender Tab in Burp Suite) and head over to the &lt;a href=&#34;https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/&#34;&gt;blog&lt;/a&gt;. Click on &lt;a href=&#34;http://demo.sjoerdlangkemper.nl/jwtdemo/rs256.php&#34;&gt;this RS256 demo page&lt;/a&gt; to go to the lab.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
