Introduction

The AIMS eCrew application is designed to help airline crew members manage their schedules and access personal information.

Our team found several access control vulnerabilities in the application. In short, users were able to access restricted functions, modify data without the proper permissions, bypass privacy controls, and even modify read-only data.

Access control vulnerabilities

Journey Log Entries access with cabin crew user

A user with cabin crew role did not have access to the Journey Log Entries menu as the following screenshot shows:

However, by calling the appropriate API endpoint directly, it was possible for a low-privileged user to modify the log entry.

Journey log entries contained take off and landing details, fuel levels, etc., so modification by an unauthorized user posed a high impact.

Unauthorized modification of discretion reports

A Discretion Report in aviation refers to a report completed by the pilot in command (PIC) or airline operations when flight duty period (FDP) or crew duty limits are extended beyond the regulatory limits due to unforeseen circumstances, such as weather delays, technical issues, or operational constraints.

A low privileged cabin crew user could modify these, even after a discretion report was submitted. This heavly affected integrity of the data in the application.

Bypassing privacy restrictions Cabin crew had the option the trade trips with each other. Crew members could share or hide their schedule with other. If a crew member hid his/her schedule, a notification appeared during a trip trade.

The request to open the schedule looked like this:

POST /eCrew/TripTrades/getCrewDuties HTTP/1.1
[...TRUNCATED...]
Connection: close
crewmember=YYYYYYY&fromRqScreen=true

Simply changing the fromRqScreen parameter’s value to false bypassed the restriciton and the application responded with the target user’s schedule.

General recommendations for access control issues

Over the past decade, we’ve seen changes in the most common vulnerabilities found in web applications. Injection-type problems are decreasing due to improved security in frameworks in this area. However, solving injection problems is much easier from a programming perspective than solving access control problems.

It’s vital to design and implement authorization early in the software development lifecycle. It’s a critical component, and developing and integrating it into an already working application is far from ideal and will definitely result in spending more resources in the end.

Designing a proper authorization system is a difficult task and depends on several factors, but you should generally keep the following in mind:

Hard-coding authorization logic is the wrong approach for complex applications. Policies and regulations change, business and user needs change, new features are developed. Maintaining a secure authorization system under these conditions is nearly impossible. Scalability becomes an increasing problem over time as the application becomes more complex and the user base grows rapidly.

Discrepancies between front-end and back-end permissions are quite common. We often see that some features are disabled in an application based on what we see in the UI, but it turns out that the same restriction is not applied in the backend logic. It’s important to build an efficient solution to handle this problem and ensure that front-end and back-end controls are in sync by enforcing the same policies.