Question:
Web Application Security Mechanisms: For the web application that you have identified in section b., what web application security mechanisms are used for authentication and why? What access control model(s) are used and why? What security controls do you plan to use to protect your organization’s data (files, databases, etc.)? What security mechanisms are you planning to use to enforce browser security and server security? (Minimum page limit: 4 pages; Maximum page limit: 5 pages). Please includes references source
SECTION B
Priceline has numerous web applications hosted within their website, though many of them are similar all require different inputs and provide different outputs. Without the necessary insight into the exact name of the chosen web application, we will refer to this application as “Trip Booking” as we explore the application in further detail. Trip Booking is hosted at the URL https://www.priceline.com/?tab=vacations which contains records as being hosted at four different IP addresses (151.101.194.186, 151.101.66.186, 151.101.130.186, 151.101.2.186).
Trip Booker is a web application that serves end users by giving them the ability to find travel arrangements for most of the needs they have for a vacation in one convenient location. Flights, rental cars, and hotels can all be searched for a specified date range of a potential trip and all of the results are provided to the end user. For added functionality the user can also specify for multiple hotels to be used over different time spans of the overall trip, as well as one way flight accommodations for the trip.
The end user for this web application is a little hard to define in more than a broad generic group as the public is the target user. Some of the users would be people looking to decide for business trips, while others could be booking family vacations. The options are nearly endless, and the users and destinations span the breadth of the world. Really the application is aimed at everyone who might have any interest in travelling to any destination in the world.
For this web application to function correctly, five inputs are required from the user. The first of these inputs is in the form of a radio button to select the needed components for the trip (hotel, flight, car, or combinations of these). Next is a departure location and then a destination location both of which take the user input and prompts for the nearest airport to the destination name provided. An interactive calendar provides select for a departure date and return date to be input, and then a number of travels selection which is broken down to include adults, children, and a number of rooms needed. Optional inputs include an option to provide separate dates for hotels, which Priceline.com refers to as “I Only Need a Hotel For Part of My Stay.”
Upon execution of the web application by the user, first a return of hotels available for the specified parameter is displayed in the browser. The outputs can at this point be filtered down based upon available criteria such as amenities or distance from a specified location. After selection a hotel for further review, output returned is a more detailed look at the room including images, available rates, and optional add-ons, total price for the duration specified as well as an ability to select the room to be added to the booking. After booking the room, output is that of a list of available flights for the user to select an appropriate flight with prices and times for each displayed. Lastly on the return is a list of available rental cars, showing different brands and price points for the trip. After selecting the rental car, the application returns a trip overview showing all of the details from the previous inputs and outputs and an option to proceed to the checkout application for the specified trip.
The architecture of the web application is closely protected, but thanks to an agreement between Priceline and HackerOne’s bug bounty program, testing was able to be done to reveal some of the architecture. The web application servers use a CDN or content delivery network to which is provided by Forter.com. “A CDN is a network of servers linked together with the goal of delivering content as quickly, cheaply, reliably, and securely as possible.” (What is a CDN? | how do Cdns work? | cloudflare n.d.) The application sits behind a WAF or web application firewall, but through reconnaissance was unable to identify which type of WAF was in use. The servers themselves have an operating system that has eluded discovery, though targeted Nmap scans have shown them to likely be hosted on a Linux host. Behind the servers, likely on the other side of the DMZ (De-Militarized Zone) would be the databases, though the type in use has also eluded discovery but is likely some form of SQL database, from review of the GET and POST messages seen when a request is made from the application. Also of unknown origin is the authenticating server, which appears to provide authentication either through locally stored (on the authenticating server) or through FIM or Federated Identity Management. “Federated login enables users to use a single authentication ticket/token to obtain access across all the networks of the different IT systems.” (Robinson, 2019) The FIM providers in use for Priceline are Apple, Google, and Facebook.
The architecture of the web application follows a very specific flow to ensure maximum availability of the service with a high degree of security for the features. When a user visits the URL of the web application a request is sent to the Forter CDN, which then will either allow the request or prompt for a captcha challenge to reduce the impact of automated hacking tools. Once the CDN has provided access, the request is forwarded through the web application firewall to the web application server. Authentication mechanisms have been seen in multiple types for the application. Firstly, is through the use of cookies and session tokens, and the second through identity management services allowing log ins to a registered account and persistence through the session tokens. The authenticating server receives the request and upon successful authentication the session is opened between the server and the client browser. On the server side, when a properly authenticated request comes in, the server queries the database, and forwards the structured response to the client browser for parsing and display of the content.
The Priceline web applications require some very specific technologies to be able to run. Client browsers are required to be of a Safari or Chromium based build for the application to run correctly. For security technology the web application requires TLS (Transport Layer Security) version 1.2 or 1.3 to be able to operate, and versions predating this will be rejected by the application. On the server side of there is the language Next.js in use, which is built upon a Node.js infrastructure to provide uniform rendering for the web application. “Rendering the same components on the server side as on the client side (universal rendering) means that development time is reduced as we can build our React components once and Next JS takes care of everything to do with re-rendering those components in the user’s browser.” (Duncan, n.d.) Also in use is Istio-Envoy to act as proxy. “Envoy is a high-performance proxy developed in C++ to mediate all inbound and outbound traffic for all services in the service mesh.” (Architecture n.d.) To enhance the speeds of such a formidable application Varnish 1.1 is used for caching the application to be able to facilitate faster load times on the client side.
SECTION C:
Priceline collects lots of sensitive data from a user due to its business operations nature. Proper authentication and security are crucial for online businesses operating worldwide like Priceline since they are great targets for hackers. A successful breach would result in gaining valuable, sensitive information, which attracts hackers worldwide. Currently, Priceline keeps records of the following aspects: legal name, address, contact information, age, date of birth, gender, IP address, credit or debit card information, device information, web logs, general device locations, specific device location (with consent), and more. Priceline may also retrieve this information from other sources like third-party applications, like Google and Facebook, third party data providers, and others. The fact that this company operates online and keeps records of aspects of such sensitive nature puts high security, authentication, and data handling standards on this company and its business affiliates.
Priceline uses password authentication for users signing in their personal accounts. A password for a personal account must be at least eight characters with a number or a special character. A user is given five attempts to enter the password correctly, if a user has exceeded all attempts, the account locks automatically and can be further unlocked by verifying your identity with Priceline customer care. User`s password is linked to a personal email; therefore, user can manually reset a password for the account via email. The website also supports Single sign-on with Google, Facebook, and Apple accounts for users’ convenience.
Priceline currently works with Okta to provide users with high-standard authentication and access controls. Okta implements centralized cloud solutions for managing Priceline and their partner applications while providing user ability of SSO and admins to manage users access across all sister applications. For authentication and access control, Okta uses LDAP protocol. LDAP is a lightweight subset of the X.500 Directory Access Protocol and has been around since the early 1990s. LDAP single sign-on lets system admins set permissions to control access to the LDAP database. It can deal with password expiration, password quality validation, and account lockout after a user has too many failed attempts. An LDAP agent can authenticate users in real-time – it compares the data presented to what’s stored in the LDAP database instantly, so no sensitive user data needs to be stored in the cloud. Okta allows admins to control their own users and enable access to a joint application–without having to worry about Active Directory trusts, firewall rules, or proxies. For access control, LDAP implements RBAC methodology, which simplifies administration by assigning roles to users and then assigning permissions to those roles.
Deploying Okta has contributed to a deeper understanding of employee app usage across Priceline. This helps IT make sure the apps they’re supporting are those that their users need and are happy with and allows the enterprise to keep better track of licenses. For Priceline, switch to Okta decreased users` down time drastically, allowed users to better self-handle sign-in problems, improved orphan accounts monitoring, enchased security, and automated many processes. Moving forward, Priceline plans to incorporate Okta’s Threat Insight capabilities to gain deeper, actionable understanding at the device level around where its users and threats are coming from. Bolstered by the wins to date, Priceline continues to actively look for ways to further integrate Okta across the enterprise. For every upcoming project, Priceline engineers plan on integrating those with Okta if possible. (Priceline | Okta, n.d.)
For any financial transactions, Priceline requires the user`s following information: full legal name, credit or debit card information including CVV code, physical address, including city, country, and zip code, personal email address, and a phone number. A user can cancel an order made on his/her name via email within 24 hours after the order was created. After every submitted order, a user gets an automatic confirmation email that includes a link to cancellation, unless a booking is a non-refundable deal. For car renting reservations, users identity is confirmed by requesting the user`s full legal name, date of birth, credit card information, and sometimes passport information for international drivers.
To receive online payments, Priceline or any other website must always be Payment Card Industry (PCI) compliant. PCI has 12 requirements, and a requirement № 8 addresses authentication issues. Here are some examples of PCI requirements: standard 8.1.1 – every user must have a unique ID before being allowed to access system components or cardholder data; standard 8.1.4 – inactive user accounts must be disabled after 90 days; standard 8.2.5 – prohibit the use of the four last known passwords. Some of the requirements listed by PCI apply to users and their authentication, while others apply to the company and its employees who have access to that sensitive information. PCI requirements might differ depending on the exposure of an employee to sensitive data. (Bartels, 2017)
To provide protection for credit card transactions while in transit, Priceline currently uses Secure Socket Layer encryption. Secure Sockets Layer (SSL) is a standard technology behind establishing an encrypted connection between a web server (host) and a web browser (client). This connection between the two makes sure that all the data passed between them remains private and intrinsic. SSL is an industry standard and is used by millions of websites to protect their online transactions with their customers. Having an SSL certificate installed is one of the 12 primary requirements set by the PCI.
Priceline currently supports HTTPS certificate for its web application which means the web site itself supports SSL standard. According to SSL Checker, Priceline uses a varnish accelerator, and SSL certificate for the website was issued by GlobalSign, which is valid from October 20, 2021, to October 20, 2024. The algorithm used by Priceline is SHA-256. The SHA-256 algorithm is one flavor of SHA-2 (Secure Hash Algorithm 2), which was created by the National Security Agency in 2001 as a successor to SHA-1. SHA-256 is a patented cryptographic hash function that outputs a value that is 256 bits long. SHA-256 is used in some of the most popular authentication and encryption protocols, including SSL, TLS, IPsec, SSH, and PGP. In Unix and Linux, SHA-256 is used for secure password hashing. Some cryptocurrencies, such as Bitcoin use SHA-256 for verifying transactions. SHA-256 is one of the most secure hashing functions on the market. The US government requires its agencies to protect certain sensitive information using SHA-256. While the exact details of how SHA-256 works are classified, we know that it is built with a Merkle-Damgård structure derived from a one-way compression function itself created with the Davies-Meyer structure from a specialized block cipher. (N-Able, 2019)
Priceline uses RSA encryption with the SHA-256 algorithm. Under RSA encryption, messages are encrypted with a code called a public key, which can be shared openly. Due to some distinct mathematical properties of the RSA algorithm, once a message has been encrypted with the public key, it can only be decrypted by another key, known as the private key. Public-key encryption schemes differ from symmetric-key encryption, where both the encryption and decryption processes use the same private key. These differences make public-key encryption like RSA useful for communicating in situations where there has been no opportunity to safely distribute keys beforehand. RSA encryption is often used in combination with other encryption schemes, or for digital signatures, which can prove the authenticity and integrity of a message. (Lake, 2021)
The latest global impact produced by COVID-19 made many companies shift to a remote operational model for employees and users. Since then, Priceline had its sight on a coffee-shop model, in which users could come and go freely between offices without going through contortions to verify permissions and authorization to the corporate assets they needed to do their work. Dropkin and his team were interested in secure remote-access technology to allow for easier least privilege enforcement and simplify the process of granting access to consultants and other third-party users. Priceline is trying to catch up with the latest trends and provide employees and users with fast and efficient modern solutions. Some of the company’s future priorities are automation and cloud implementation. For those purposes, the company is planning to work with industry known secure solutions providers.
Priceline will comply with any future requirements of PCI for encryption and anonymizing a standard like CCPA for customer data protection. GDPR as one of the newest and most wide-ranging standards will affect Priceline as well, since Priceline operates worldwide and has customers who are individual subjects to the EU’s jurisdiction. Some of the GDPR requirements include having a data protection officer and using standard contractual clauses when sharing data with non-EU-based organizations. For browser and server security Priceline will comply with any possible U.S. regulations and follow best guidelines.
———-
Question:
Web Application Security Mechanisms: What web application security mechanisms are used for authentication for the web application you mentioned in section b., and why? What model(s) of access control are employed, and why? What security controls do you intend to implement to safeguard your company’s data (files, databases, and so on)? What security techniques do you intend to employ to ensure browser and server security? (Minimum page limit: 4 pages; Maximum page limit: 5 pages). Please includes references source
SECTION B
Priceline has numerous web applications hosted within their website, though many of them are similar all require different inputs and provide different outputs. Without the necessary insight into the exact name of the chosen web application, we will refer to this application as
