Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Security Engineer in the Web Re-architecture Project

6aaffafb38a160209c9164da25b3a3f3?s=47 Yu Yagihashi
September 12, 2018

A Security Engineer in the Web Re-architecture Project

Mercari Security Engineer Meetup #mercari_security

6aaffafb38a160209c9164da25b3a3f3?s=128

Yu Yagihashi

September 12, 2018
Tweet

More Decks by Yu Yagihashi

Other Decks in Programming

Transcript

  1. A Security Engineer in the Web Re-architecture Project 2018.09.12 Mercari

    Security Meetup#1 Yu YAGIHASHI
  2. Presenter Yu YAGIHASHI a.k.a やぎはしゅ - Security Engineer - Joined

    Mercari, Inc. in Jan. 2018 - Specializing in Web Application Security - GWAPT, GWEB, GCIH - Twitter & GitHub: @yagihashoo - https://xss.moe/
  3. What I’m Talking About Tonight • Web Re-architecture at Mercari

    • Security challenges of Re-architecture * Most of the talk today is from ongoing projects. So some of them are not concluded yet, most of them are still being implemented.
  4. Web Re-architecture Motivation toward Next Web

  5. https://speakerdeck.com/sota1235/road-to-migrate-jp-web-as-a-microservice

  6. Mercari JP Web So Far • Service provision for new

    customers ◦ Access with PC ◦ Access without native apps • Spread using the Web ◦ SEO ◦ SNS sharing features • Features used on both Web browsers and native apps(WebView) ◦ Mercari Box ◦ Help Center
  7. Problems Feature difference from iOS/Android Architecture

  8. Problems Feature difference from iOS/Android Architecture

  9. Feature difference from iOS/Android • Mercari JP Web has limited

    functionality ◦ Purchase items ◦ Sell items ◦ Search items • Only native app has access to all features and functions ◦ Some of delivery methods ◦ Offer ◦ Follow ◦ And many more...
  10. Problems Feature difference from iOS/Android Architecture

  11. Architectural Problem • Monolithic architecture ◦ Given the current scale

    of development division, microservices architecture should be better • Not good for frontend engineers to develop, maintain, and improve it ◦ PHP Web application, jQuery, and just a little React • Hard to follow migration to microservices architecture in backend services ◦ Too many specific dependencies with backend services
  12. So... • We shouldn’t just copy apps ◦ We’d like

    to port the features which are also useful for Web customers ◦ On the other hand, Mercari JP Web dependent features that can be later copied to other platforms would be nice • Why Web? Aren’t Native apps enough? No :( ◦ Mercari JP Web is also an important factor for Mercari ◦ We believe it has huge potential for better UX and more benefits through optimization • It’s time to improve Mercari JP Web ◦ For better features and UX ◦ To build a better architecture for easier development ◦ For easier to maintain code
  13. Re-architecture JP Web Architecture for a New Web

  14. What We Will Realize with New Web • Speed up

    the evolution of Mercari JP Web ◦ Make foundation for the challenges towards cutting-edge technologies ◦ ex.) PWA, new frameworks, new libraries • Support cooperation among teams and engineers ◦ Loosely-coupled backend and frontend ◦ Architecture which won’t fail even if it’s developed by 100 frontend engineers and 10 teams
  15. Monolithic to Microservices Mercari Box Backend Frontend Mercari Backend Frontend

    Mercari Guide Backend Frontend Single repository ➔ Multiple services in a single repository ➔ Both backend and frontend in a single repository ➔ No team in charge, no ownership Mercari Box REST Frontend Mercari GraphQL SSR Mercari Guide Backend 1 service, 1 repository ➔ Separation between services ➔ Separation between backend and frontend ➔ Everything up to the owner team
  16. Web Re-architecture Security Moving on to Next SECURE Web

  17. Quick-look on New Architecture ❶ ❷ ❸

  18. Discussions and challenges 1) Sync up user session among Client,

    SSR, and Current Web 2) Access controls on GraphQL 3) Enforce Content Security Policy on Mercari JP Web * These are just examples to introduce how we work and how we think in our projects, not necessarily introductions of the actual implementation
  19. Session Sync New Web will be released as part of

    the current Mercari JP Web. Sharing user sessions between them is one of requirements. But… how? 1) Without session duplication, fetch session information to Current Web everytime a) Session information contains credentials to connect with Mercari API, we shouldn’t scatter this b) We’ll definitely face latency problems 2) Duplicate session information on first access, and use copied information after that a) How can we recognize the session has expired or been destroyed?
  20. Session Publication and Management Flow SSR GraphQL Current Web Session

    Sync G a t e w a y ❶: Current Web is responsible for issue of session cookie and sending back to clients Mercari API ❷: If New Web receives session cookie which Session Syncing service doesn’t know, Session Syncing Service will fetch session information to Current Web and store cache ❸: Due to SPA for New Web, there will be time lag between session expiring on server side and ion client side
  21. Session Publication and Management Flow SSR GraphQL Current Web Session

    Sync G a t e w a y Mercari API ❸: Due to SPA for New Web, there will be time lag between session expiring on server side and on client side ❸-a: Confirm session status with Mercari API (a)synchronously ❸-b: Attach session status into every GraphQL response
  22. GraphQL • It provides more flexible data fetch and manipulation

    for frontend • Although it depends on the implementation, there are several points to watch out for • Let me propose discussion on access control in GraphQL
  23. Access Control in GraphQL type User { id: ID! @unique

    email: String! @unique password: String! screenName: String! lastName: String! firstName: String! postalCode: String! address: Address! createdAt: DateTime! updatedAt: DateTime! } type Query { user(id: ID!): User item(id: ID!): Item items: [Item!]! } type Item { id: ID! @unique seller: User! title: String! description: String! image: String! price: Int! } { item(id: "cjlmjhcacnc780b17v481emrj") { title description image price seller { id screenName address { prefecture } } } } Defined Schemas Example Query for item details
  24. Access Control in GraphQL type User { id: ID! @unique

    email: String! @unique password: String! screenName: String! lastName: String! firstName: String! postalCode: String! address: Address! createdAt: DateTime! updatedAt: DateTime! } type Query { user(id: ID!): User item(id: ID!): Item items: [Item!]! } type Item { id: ID! @unique seller: User! title: String! description: String! image: String! price: Int! } { item(id: "cjlmjhcacnc780b17v481emrj") {  ・  ・  ・ seller { id screenName password address { prefecture } } } } Defined Schemas If someone uses a query like this...
  25. Content Security Policy • Enforce CSP for protecting customers using

    JP Web • Start with report-only mode • Looking for good logging method and good policy for both security and development
  26. Summary • Not only security testing! ◦ We’re also in

    charge of supporting software engineers to architect new applications • Fun and challenging ◦ Coexistence of a new architecture and an old architecture sometimes creates unique security challenges • Easy access to the real code ◦ If we need something, we can implement it by ourselves ◦ Code repository is open to everyone
  27. We’re hiring ! Join us and have fun with security.

    Thank you for listening.