Authentication vs. Authorization in Web App Penetration Testing
文章探讨了网络应用渗透测试中身份验证与授权的区别及其重要性。通过比喻音乐会入场与权限控制,解释了身份验证用于确认用户身份,而授权则决定用户访问权限。文章还举例说明如何绕过身份验证和授权机制,并强调两者在安全测试中的关键作用。 2025-6-4 17:5:52 Author: redsiege.com(查看原文) 阅读量:0 收藏

by Douglas Berdeaux

Introduction

Authentication and Authorization in web application penetration testing are so closely related, that it’s easy to confuse the two. This article aims to outline each process, aid in understanding the differences between the two, explain why each is equally important, and assure that readers are using the correct language surrounding these two topics. Authentication and authorization are heavy hitters in penetration testing. For this reason, it is important to ensure that we are communicating test results, findings, and remediation efforts to our clients properly. Let’s begin with a fun little analogy using a concert.

Authentication

When we think of how we access web applications, we are most likely thinking of authentication. Let’s say that a private organization located within a popular college town has decided to host an event specifically for college students currently enrolled in the surrounding universities. This event will be complete with a live band to provide entertainment, a snack bar, and an alcoholic beverage bar. To get into the event, students will need three things:

  1. A university provided email address

  2. A mobile device to receive a one-time code as a form of multi-factor authentication (MFA)

  3. A valid state-issued ID card, such as a driver’s license

Now, we can think of the employed individual (i.e. bouncer) standing at the entrance to the event as the authenticator. The authenticator checks all the information provided by the student and, if valid, will stamp the back of the student’s left hand using a stamp that is unique to the event in blue ink. We can think of the blue stamp on the hand as the student’s session cookie. It allows students to freely walk around in the event and is only valid for this particular event. To make the verification process more seamless at the alcohol bar, the authenticator at the entrance of the event will also stamp the back of the student’s right hand using green ink if the student is at least 21 years of age.

Authentication Assessment

Finally, now that we have our working analogy, we can start to think, as hackers, how to defeat authentication and authorization. First, let’s try to bypass the authentication completely. To do so, we simply attempt to scale the fence around the event. Unfortunately we can’t because the organization has security folks walking the perimeter. Since authentication can’t be completely bypassed using this method, let’s try to find a flaw in the authentication process itself.

We wait in line to the event and when it is our turn we present the authenticator with a valid university email address that we found somewhere online. The problem here is that we don’t have access to the email inbox, so when the authenticator emails the MFA code that we are to relay back to her, we never get it. But, we do notice that we can observe the MFA code in a reflection of her iPad screen from the glass of a picture frame located on the wall just behind her. We tell her the code, she stamps the back of our hand with the blue stamp, and we are let into the event. MFA bypasses are rare in web application penetration testing, but they do occur. In this case, we can think of the flaw that we identified in the MFA process as excessive data exposure since we observed the MFA code without even accessing the email inbox.

OK, so let’s assume we bypassed authentication and we now have a blue stamp on our left hand that indicates that we are authorized to be in the event area. When we reveal our state-issued identification card the authenticator notices that we are not yet 21 years of age so the blue stamp on our left hand is the only stamp that we have as we continue.

When we think of access to web application functions and data, we are most likely thinking of authorization. Session cookies and bearer tokens are typically used for authorization in web applications and are used to determine who has access to what often using various roles. But, in our example, we will still use the hand stamps analogy we came up with in our concert analogy. Remember, if the student has a green stamp on the back of their right hand, provided by the authenticator upon entering the event, then the bartender knows that the student is permitted to enter the bar. This is analogous to roles. Some students attending the event will have a “student” role and will be authorized to consume food from the snack bar and watch the band play. Others can do all of those things but are also authorized to drink alcohol if they choose as part of the “student+adult” role as they are 21 years of age or older.

Authorization Assessment

Now that we have successfully defeated authentication and are in the event area with a valid blue stamp on the back of our left hand, our next step might be to see if we can defeat the authorization requirement of the “student+adult” role’s green stamp on the back of the right hand to access the alcohol bar. Well, we would probably first attempt to not show our hand at all and see if we can enter the bar in the event area. I use this technique all the time during web application penetration tests by simply force browsing application programming interface (API) endpoints without session data. This type of test may reveal broken authorization issues such as broken object, or function-level authorization. Unfortunately, this attack didn’t work as the bartender absolutely requires us to reveal our right hands before allowing anyone to enter. Good on you, bartender.

Well, what if we applied a yellow marker to our blue stamp on the back of our left hand to change the blue color to green? We can think of this as tampering with session cookies set in our web browser to attempt privilege escalation or lateral movement and is something that penetration testers do during every assessment. Now we have a green stamp but there’s still the problem of our green stamp being on the wrong hand! We know that the blue stamp is on the left hand and the green stamp is on the right. If we present the green stamp on the wrong hand surely the bartender will reject it but that’s probably not the only thing wrong here. For instance, what if we did a poor job when changing the stamp color using the yellow marker and we draw outside of the lines or the marker bled heavily due to the difference in ink quality? The bartender should notice this right away and reject our request to enter the bar sending us back to the authenticator in case there’s a valid reason why our stamp was suspicious. Again, kudos to you, bartender!

Conclusion

The differences between authorization and authentication should be clear by now. Authorization ensures that the session data generated by the authenticator is valid and belongs to the user requesting the data or functions within the web application and its API endpoints. Authorization actually makes up so much of what we do as web application penetration testers that it claimed multiple entries in the OWASP Top Ten API and the standard Top Ten lists. Authentication is just as important as it is responsible for generating our session data. In this case it was simply colored stamps on the back of our hands. Without authentication, anyone would have been able to enter the concert event thereby defeating the intention of providing something special only to college students.


About Douglas Berdeaux, Senior Security Consultant

Douglas was a manager of a Red Team for a consulting company and has performed penetration testing for clients with high security maturity on internal networks, internal and externally facing web applications, and desktop applications. Douglas was a full-stack enterprise-class web developer for close to a decade building, securing, and testing the security of business-critical web and mobile applications. He has taught cybersecurity as an adjunct professor for Duquesne University and has published multiple books and articles about penetration testing, hardware hacking, and programming.

Certifications:

OSWP, OSCP

The Aftermath Part 4: The Vendor Requirement

By Red Siege | June 2, 2025

by Jason Downey The Vendor Requirement The final entry in The Aftermath blog series. At this point, I had successfully social engineered credentials, bypassed multifactor authentication, and established command and […]

Learn More

The Aftermath Part 4: The Vendor Requirement

The Aftermath Part 3: The Simple Stuff

By Red Siege | June 2, 2025

by Jason Downey The Simple Stuff So far in The Aftermath Blog Series, I had social engineered credentials, bypassed MFA, and gained access to a VDI environment. In this entry, […]

Learn More

The Aftermath Part 3: The Simple Stuff

The Aftermath Part 2: The Condition

By Red Siege | June 2, 2025

by Jason Downey The Condition In the first entry of The Aftermath Blog Series, I was able to social engineer a set of domain credentials. In this entry, we’ll discuss […]

Learn More

The Aftermath Part 2: The Condition


文章来源: https://redsiege.com/blog/2025/06/authentication-vs-authorization-in-web-app-penetration-testing/
如有侵权请联系:admin#unsafe.sh