WTF is HAST?

It’s Human Application Security Testing. 

I coined the term a few years back when explaining that while SAST and DAST are important when testing APIs, the more impactful security vulnerabilities will be found by people manually creating tests to examine how the apps and APIs function. 

This unique value is what HAST brings to the table.

The thing was, “manual testing” was a poor descriptor. Yes, a human has to create the tests. But there was no reason the tests couldn’t run automatically. Hence, the term HAST was born.

Ummm… why not call it MAST then?

Because MAST was already used; that’s mobile application security testing.

Anyway, during the latest APISEC|CON conference, when I was presenting Corey Ball mentioned to me that HAST wasn’t a term in his lexicon.

That surprised me for a moment, but then it made sense; I haven’t really shared the purpose and value of HAST with a larger audience outside of the teams I work with.

So here goes. 

Let me explain why HAST should be important to you as an API hacker.

What is HAST?

Let’s put some terms into perspective.

• Static Application Security Testing (SAST): It’s a method of analyzing source code or compiled applications to identify security vulnerabilities without executing the program. Think of it as testing from the inside out.
• Dynamic Application Security Testing (DAST): It’s a security testing method that analyzes a running application to identify vulnerabilities by simulating external attacks. Think of it as testing from the outside in.

Are you considered a DAST as an API hacker? Some may say you are, but I don’t.

Legacy DAST tools sometimes report vulnerabilities that do not actually exist (false positives) or miss real vulnerabilities (false negatives), requiring manual validation and remediation. That’s because it blindly applies attack patterns and potentially malicious payloads without understanding the context of the request.

The result? Those pesky humans have to get involved anyway.

And if humans have to get involved to validate all the potential false positives manually, doesn’t it make sense to build the more complex tests manually?

That’s Human Application Security Testing (HAST).

DAST vs. HAST

I’m not saying DAST is bad. It has its place. The Burp Suite Web Vulnerability Scanner is a great example, especially with its new API scanner capabilities. Or 42crunch’s API Scan which conducts dynamic API security testing based on API contracts defined in API spec docs like OAS. 

But HAST is different. It allows you to build tests that function with an understanding of the context of requests in the app and API. Especially when the API docs may themselves lack proper definition and design.

For example, an API document may state that a property in a POST is expected to be an integer. But in many cases, it doesn’t define the value range of the number. If this isn’t described properly in the API documentation and is implemented incorrectly in the code, there may be opportunities to attack it by abusing its lack of bounds checking. 

This is precisely how integer overflows occur in APIs.

Why API Hackers should care about HAST

Now to the reason why HAST is important to API Hackers. It’s all about the depth and breadth of test coverage against the known attack surface you have found.

People in the bug bounty world typically test very shallow into their targets. In fact, many “bug bounty influencers” out there will tell you that you want targets with huge scope that you can quickly scan and test.

That’s a terrible idea if you are focused on API hacking.

I’ve discussed this before when discussing when to give up on a bug bounty target that has APIs. The fact is that you will need to invest time to truly understand how the API functions. Why not maximize that time investment?

HAST can help.

Here’s how.

1. Build reusable tests that can be automated

Sure, it may be fun to run Intruder attacks in Burp Suite manually. But wouldn’t it make more sense to invest the time into learning how the endpoints work and then build tests that can continuously run on an automated basis to detect changes and regressions in the API endpoints you are hacking?

So even if you don’t find a vulnerability today, you won’t have to thoroughly test it again manually tomorrow.

You can import API spec doc into Postman to generate a collection of known “expected” behaviors. Then you can clone that into a new collection which you can weaponize… allowing you to reorganize and exploit accordingly.

Then you can run tools like the Newman CLI to execute your Postman collection of security tests regularly. If you work with the development teams building the APIs, you can even hook this into the CICD pipeline and run the tests every time a new build is executed.

This means your investment in HAST will continuously run in an automated manner, even when you aren’t there. Tie the results to a webhook or notification script; your HAST can alert you when something is found.

Nothing beats getting a Slack message in the wee hours of the morning telling you a new security vulnerability was detected in an API endpoint you haven’t looked at in months on a target you aren’t even thinking about.

2. Validate data even when the API contracts suck

Most security vulnerabilities found in APIs start with manipulated data. While DAST tools are limited to examining API endpoint definitions as they are described, you can build tests based on context and intent. 

This means your tests can validate the actual implementation and see how to break out of it. You can explore things like mutation rules to bypass input validation in far more detail. And you can manipulate and tailor malicious payload databases specifically for the API. All because HAST gives you visibility and understanding of how the app and API function together.

For example, the Postman Collection Runner supports the concept of data files, which allows you to inject different payloads at runtime. This means you don’t have to alter tests to add new payloads you want to validate; you just need to add them to the data file. This opens up an entirely new world for attacking APIs by tainting data in weird places.

I cover some of this in my API Hacker’s Guide to Payload Injection with Postman.

3. Discover new API endpoints and code paths before others do

With tools like oasdiff, you can detect breaking changes, additions, or modifications made to an API’s contract over time.

Using HAST, you can build out your own logic to intelligently inform you of new endpoints that expand the attack surface of your testing. You can also see changes that may alter your testing strategy, giving you early access to a window of potential vulnerability of new code.

Why does that matter? It means there is a better chance you will find security vulnerabilities in new code before your adversaries do — or fellow bug hunters if you are into that sort of thing.

Fewer dupes. More whoomps.

4. Validate False Positives from DAST

As I mentioned before, DAST isn’t bad. But its results need to be verified. 

Through HAST, we can validate the results from DAST scans, reducing the time spent investigating false positives and ensuring that identified vulnerabilities are valid and exploitable.

More importantly, once developed, these tests become the foundation for regression testing, ensuring that once remediated, these vulnerabilities are not reintroduced in the future without detection.

When HAST is used as part of a developer’s CICD pipeline, it can even be used as a security guardrail to prevent a push to production by detecting regressions on test/staging deployments.

5. Complex attack chains are realistic due to contextual understanding

Some of the more impactful security vulnerabilities in an API come from complex attack chains of several API requests used in a particular sequence. DAST tools usually can’t see past the individual requests.

HAST allows you to understand the business logic and apply more thought to the exploit paths. It also allows you to chain less critical vulnerabilities together to develop more critical exploits with more damage potential. 

Why is this important? It allows you to develop creative attack vectors and use unconventional testing methods that go beyond the predefined patterns of DAST tools.

Remember, we aren’t trying to validate that API endpoints work as intended; security testing is about making APIs work in ways NOT intended.

Conclusion

Human Application Security Testing (HAST) brings a unique and valuable perspective to API security. By leveraging human insight and creativity, HAST allows testers to dive deeper into the nuances of API functionality, uncovering vulnerabilities that automated tools like SAST and DAST might miss. 

HAST allows you to create reusable, context-aware tests that you can automate to ensure continuous security validation, even in dynamic development environments. It provides a way to validate data beyond the limitations of API contracts, discover new endpoints and code paths, and confirm the results from automated scans. 

Ultimately, HAST empowers API hackers to identify complex attack chains and develop sophisticated exploit strategies, making it an essential approach for thorough and effective API security testing. 

By integrating HAST into your security practices, you can maximize your efforts, minimize false positives, and ensure that vulnerabilities are detected and addressed promptly, safeguarding your applications against potential threats.

So ya, HAST is important. 

Don’t you agree?

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.

The post Why HAST is important to API hackers appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/why-hast-is-important-to-api-hackers