Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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/

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

Web Re-architecture Motivation toward Next Web

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Problems Feature difference from iOS/Android Architecture

Slide 8

Slide 8 text

Problems Feature difference from iOS/Android Architecture

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Problems Feature difference from iOS/Android Architecture

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Re-architecture JP Web Architecture for a New Web

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Web Re-architecture Security Moving on to Next SECURE Web

Slide 17

Slide 17 text

Quick-look on New Architecture ❶ ❷ ❸

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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?

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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