The Grammar of Injection Attacks

 

I'm presenting a talk in Null OWASP Bengaluru Meetup on 25th April 2026.  It is a talk that focuses on foundation of injections in web applications.  I wish, I had a senior or mentor who would have walked through me this in the early days of my career.  However, Rahul Verma's workshop on web security helped me to build the perspectives -- I take this opportunity to thank and express my gratitude for him.

It's Just Data..., Until It Isn't: The Grammar of Injection Attacks

In modern web applications, user input is everywhere -- search boxes, login forms, URLs, and APIs.  Most of the time, it is treated as harmless data.  But what happens when the data is interpreted as code?

This talk introduces a fundamental yet often overlooked concept behind vulnerabilities like HTML injection, SQL injection and Cross-Site Scripting (XSS): grammar and context.

Instead of focusing on memorizing payloads, we will explore how browsers, databases, and interpreters parse input.  Later, we will learn how the attackers exploit these rules to break out of intended contexts.  Through simple, real-world examples, we will walk step-by-step through how an attacker reads the structure of a target, identifies injection points, and crafts payloads that turn data into execution.

By the end of this session, you will have a strong mental model to:

• Understand where and why injection vulnerabilities occur
• Analyze how input is interpreted across HTML, JavaScript, and SQL contexts
• Think like an attacker and defend like an engineer.

This talk is designed for beginners in security, testing or development who want to build a solid foundation in web vulnerabilities without getting lost in complexity.

Prerequisite:  An open mind and do not keep the questions unasked and undiscussed.

null and OWASP Bengaluru Meetup - 25th April 2026

Backtracking of Testing, Security and Tools

 

When I started my software testing career in 2006, I was in this thought -- What tools should I use, so that,

• I can do the testing that is sought after
• I can test for performance
• I can test for security

Moving from a search for tools to building the mindset and attitude.  It is a journey!  It took me time to see this journey.  I hopped on to this journey in 2011.  I see, this is not an ending journey, while I know where should I go and reach.  I'm on this journey.

I had no mentors.  I had no seniors in software testing to guide and discuss on my thought process.  I had developers (programmers) who had little or no interest in testing; so it did not matter to them.  But, they have helped me to be better tester.  I'm grateful to them.  Then, the community was not so connected, organized and share the knowledge as it does in 2024.  The software testing was not considered or seen as a technical activity, then.  I have stood, fought, demonstrated and delivered my testing as a technical activity.  I'm continuing it.

Today, on 24th Feb 2024, I read the below question in a community's social space and decided to write this blog post.

Hey, everyone .... Can anyone please suggest a good tool for API security testing?

This question resonates in test engineers.  Most of we test engineers still look and ask for tools when it comes to security testing.  To test engineers, the performance and security testing are still a conception and activity with tools alone.  In reality, it is not!  If you are in such thought or you come across such question to answer, this blog post is for you.

Backtracking the Problem Identification

In programming, we have an approach by name Backtracking.  It is about exploring in possible ways to find possible solutions for a problem.  And, a best solution which works in context is picked.

What's the problem here?  Testing, Security and Tools. Are you with me so far? Let us backtrack this problem.

Note: I see a difference between the words 'possible' and 'all'.  Hence, I use the words "possible ways" and "possible solutions" and not "all ways and all solutions".

Bounties and Entry

There are reputed bug bounties for security testing.  To get into this bounties one has to showcase her/his discoveries and skills with her/his recognized portfolio.

The tools are accessible to all.  The community edition and licensed edition tools are available.  We use these both editions of tools.

• But, why not all of us with tools cannot get into such invited security bug bounties?  
• You will answer this question if you ask yourself.  Hope this backtracking should have helped by now!

The Security Engineering is a vast practice area in Software Engineering. There are dedicated security engineers in role.  But, we test engineers can take up the testing for the security of software systems which the team is programming and building.

I advise, a practicing test engineer

• To start with building an interest for security engineering.
• Consistently hone and build the mindset, attitude and skills needed for the testing the security aspects.
• Pick simple problems, solve it.  Do it consistently, while you explore the layers.

While this is done consistently, it is time to find the mentors in Security Testing. The mentors will assist you in practicing how to test effectively for security making use of simple contextual necessary tools.  Also, a mentor will let you know how to test for security without tools to an extent.  The tool is effective when known how to use it.  The tools help immensely only if I can test for security. 

To backtrack in a different perspective, did any tool that you use, find a P1 security problem [or risk] by itself in its scan?  Did your programmers acknowledge to that risk or problem?  I will pause with these two question to you.

Today, my testing for security is confined to systems that I test.  I test for web application, mobile apps, web APIs, and database.  I can assist here, if you do the home work and ping me.