修复 React 应用中的安全漏洞以防止 API 漏洞利用_AI阅读总结 — 包阅AI

Over the past several years, React and Angular JavaScript frameworks have been among the most popular choices for developers building data-driven enterprise websites and applications. While these frameworks are robust and provide built-in security features, mistakes can still be made that could lead to security issues.

The Traceable ASPEN team continues to discover a common anti-pattern in single-page applications: the underlying server-side API does not properly authenticate users, or authentication is missing entirely. These APIs are often developed alongside the client-side application, and developers usually think the security implemented on the client will provide enough protection. We disclosed one such vulnerability with a Fortune 500 company’s Angular application a few months ago, and we are excited to unveil our latest discovery in a Siemens React web application.

Siemens AMA Cloud

Siemens develops and maintains a cloud system named AMA Cloud. AMA stands for “Asset Management Assurance.” The website is a React application, making it a prime API discovery and exploitation target.

Disabling Microsoft SSO

In React or Angular applications that implement SSO, there are typically two ways developers design the initial loading of the application:

1. A custom-designed login screen will be presented, welcoming users. There will be a login button the user would click on and be redirected to the SSO provider.
2. No login screen or other UI is loaded at all. Instead, the user is immediately redirected to the SSO provider.

The website uses method #2. Even though you are immediately redirected to the Microsoft SSO page, there is a brief window where the entire React application is loaded. We took advantage of this window to view the application’s source code and see how it works. Since we cannot log into a real Microsoft account, the login redirect must be disabled for the web app UI to load. The only way to do this was to modify the client-side JavaScript code to comment out the redirect. Doing so stops the web app from redirecting to the Microsoft SSO page.

Faking a JWT

With the login redirect out of the way, the next step was understanding how authentication and authorization worked beyond that point. We found that the login token gets stored in the browser’s session storage, and the web app decodes the JWT to load the user information and, more importantly, the JWT’s expiration date. This approach has nothing wrong as long as the complete JWT is sent with every API request so the server can verify the login is legitimate.

A standard attack we will attempt is to create a “fake” JWT for the browser’s local/session storage and populate it with enough information to get the app to load without errors. This can be an easy way to determine whether the server-side API correctly checks for a valid token. We found an unauthenticated getUsers API endpoint.

This gave us all the information we needed to fill in our fake token with accurate information. We looked for a user that had access to everything and created a JWT to that effect:

The signature was unnecessary because it was not verified on the client side. Even if it were, it would have been trivial to bypass. The next step was to put the token into session storage:

Admin Access Achieved

With the JWT in-session storage and modified JavaScript applied, an attacker could load into the website and gain full access. The fake JWT worked because the JWT wasn’t being sent to the API server at all — it was only used on the client side. All the APIs were unauthenticated. However, it was still necessary for the information in the JWT to be accurate because the API used the user information in some requests:

Reporting to Siemens

The Traceable ASPEN team compiled a report and sent it through Siemens’ vulnerability disclosure program. The timeline is as follows:

• Tuesday, Jan. 30, 2024: Report sent. Less than an hour later, Siemens confirmed they received the report.
• Wednesday, Jan. 31, 2024: Siemens thanked us for reporting the vulnerability and offered Hall of Thanks.
• Thursday, Feb. 1, 2024: We confirm the vulnerability is fixed and provide information for Hall of Thanks credit. We also inquire about the possibility of a coordinated disclosure.
• Monday, Feb. 12, 2024: We follow up on our Feb. 1 email.
• Thursday, Feb. 15, 2024: Siemens confirms support for public disclosure and asks several questions about our plans. We will provide answers shortly after.
• Tuesday, Feb. 20, 2024: Siemens requests we share a blog draft when ready.
• Thursday, April 11, 2024: We share a blog draft with Siemens for feedback and approval.
• Monday, April 22, 2024: Blog feedback received from Siemens.
• Monday, May 13, 2024: Final blog sent to Siemens for approval.
• Wednesday, July 31, 2024: Published

Siemens was highly responsive to our vulnerability report. They promptly fixed the vulnerability by updating the client-side code to send the authorization token for every request and updated the server-side API to require it. Their vulnerability resolution program is a testament to their commitment to security and privacy.

Lessons and Takeaways

This was another example of missing/broken authentication — a common problem in the industry that continues to result in data breaches and damage to critical systems. When building your APIs, one of the first questions you should ask yourself is: do my APIs use the Authorization header? The first step is sending it to the server, but a sometimes missed second step is ensuring the API server validates the header and correctly rejects clients that send a missing or invalid value. Server-side validation of the JWT signature is also vital to provide users with who they say they are. While client-side validation can also be done, it is not recommended because the JavaScript can be modified to remove such validations.

Traceable ASPEN

Traceable ASPEN provides vendor-neutral and threat-driven research in API security, investigating the latest breaches with world-leading expertise and analysis. We believe in securing the world’s APIs with actionable insights from across the industry.