Hacking the largest airline and hotel rewards platform (2023)

Incident response and vulnerability disclosure

  • Many commenters are impressed that points.com repeatedly:
    • Acknowledged reports within an hour.
    • Took affected sites offline quickly.
    • Deployed fixes rapidly.
  • This is contrasted with common experiences where security reports sit in generic inboxes for hours or days.
  • Some speculate they use security.txt plus a managed disclosure program, possibly with 24/7 operations-style monitoring and escalation.
  • Others note a disconnect: incident response is very strong while some underlying bugs are extremely basic.

Bug bounty culture and incentives

  • Several comments criticize parts of the web bug bounty community as ego-driven and impatient toward companies.
  • Desired changes:
    • More and better-paid bounties.
    • Less public shaming and more professionalism.
  • There is concern that “move fast and fix” expectations could be abused as a social-engineering vector (e.g., fake reports that pressure rushed, unsafe changes).
  • Example cited of a very high bounty for an error involving an accidentally pasted cookie, raising questions about what counts as “skill.”

Basic security failures (e.g., SECRET_KEY="secret")

  • Commenters are shocked that a global admin site used “secret” as the Flask session key, enabling cookie re-signing with superadmin rights.
  • Explanations offered:
    • Example code copied with a placeholder key.
    • A ticket to replace it with vault-managed material is never completed.
  • Debate on session design:
    • Some argue cookies should only store an opaque ID, with all auth data server-side.
    • Others defend Flask’s signed-cookie model but stress the need for strong, protected keys.
  • Framework comparisons:
    • Django is praised for generating random secret keys and using DB-backed sessions by default.

Development practices vs. security practices

  • Discussion on how “donkey” development practices can coexist with sharp security teams.
  • Some argue organizations should move strong security talent into build teams to prevent vulnerabilities earlier.
  • Others note many security specialists don’t want to be developers, so simple reshuffling isn’t realistic.
  • Several mention common patterns:
    • Weak or default secrets in dev that leak into prod.
    • “Temporary” shortcuts and tech debt turning into long-lived attack surface.

Airline, GDS, and rewards ecosystem insecurity

  • Commenters generalize from the article to the broader travel industry:
    • Rewards portals often feel like low-quality reskins with poor security.
    • Many airline systems rely on easily guessed or exposed identifiers (PNR + surname) to access and sometimes modify bookings.
    • Boarding pass barcodes can leak these identifiers; posting them online can enable itinerary tampering or denial-of-service (cancellations).
  • Trade-offs highlighted:
    • Stronger auth and MFA would increase complexity for many interconnected parties (airlines, GDSs, OTAs, hotels, agencies).
    • Some defend the current model as a pragmatic balance between usability, interoperability, and risk.
  • Others describe deeper, legacy issues:
    • Arcane and brittle GDS backends.
    • Misconfigured or exposed endpoints that can be abused for fare manipulation, refunds, or “fuel dumping”-style exploits.
    • Tech debt is high; fixes are expensive, and abuse is traceable enough that systems often remain unfixed.

Whether to take sites offline for vulnerabilities

  • One camp: with significant financial exposure, once a critical flaw is proven, keeping the system online is unacceptable, possibly illegal or insurance-violating.
  • Another camp: the “optimal amount of fraud is non-zero”; if exploitation isn’t widespread and uptime is highly valuable, some organizations might rationally keep running temporarily.
  • Counterargument: knowingly running with a “broken lock” on other people’s assets is ethically and legally different from tolerating minor shoplifting.

Rewards programs and economics

  • Some users say rewards portals are inherently second-class systems because they cost money rather than directly generating revenue.
  • Others counter with experiences of extremely profitable but technically crude revenue-generating systems.
  • A security researcher notes airline bounties paid in miles can be tax-inefficient:
    • Points are treated as taxable gifts, generating tax bills that can exceed the value of flights compared to just paying cash.

Meta observations

  • Commenters see these vulnerabilities as:
    • Evidence that well-known, decades-old issues (directory traversal, weak secrets, authz mistakes) remain common.
    • A natural result of early-stage shortcuts that survive growth until an external researcher exposes them.