A Security Engineer in the Web Re-architecture Project

Mercari Security Engineer Meetup #mercari_security

Transcript

1. A Security Engineer in the
   Web Re-architecture Project
   2018.09.12 Mercari Security Meetup#1
   Yu YAGIHASHI
   

   View Slide

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/
   

   View Slide

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.
   

   View Slide

4. Web Re-architecture
   Motivation toward Next Web
   

   View Slide

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

   View Slide

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
   

   View Slide

7. Problems
   Feature
   difference from
   iOS/Android
   Architecture
   

   View Slide

8. Problems
   Feature
   difference from
   iOS/Android
   Architecture
   

   View Slide

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...
   

   View Slide

10. Problems
    Feature
    difference from
    iOS/Android
    Architecture
    

    View Slide

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
    

    View Slide

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
    

    View Slide

13. Re-architecture JP Web
    Architecture for a New Web
    

    View Slide

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
    

    View Slide

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
    

    View Slide

16. Web Re-architecture Security
    Moving on to Next SECURE Web
    

    View Slide

17. Quick-look on New Architecture
    ❶
    ❷
    ❸
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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...
    

    View Slide

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
    

    View Slide

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
    

    View Slide

27. We’re hiring !
    Join us and have fun with security.
    Thank you for listening.
    

    View Slide