關於mobile做authentication security

[itdog][mobile, security, oauth][其實IoT可能都關事(唔熟)]

關於mobile做authentication security問題。
之前可能講過, but我都再講多次, 重要野唔怕一講再講。

Mobile App裝o係Mobile,你就要預左好似frontend javascript咁赤裸俾人睇晒。
因為hacker可以crack mobile
=>拎到APK file
=>decompile做source code

我舉個例子,mobile app用OAuth Authorization Code Grant Flow做authentication。
好多人都係咁做,好多industrial專業engineer都可能係咁做。(就算vendor如pingIdentity, 佢地個網都係咁講架ja)

但以大眾做法,我(or hacker)好似上面咁講,decompile source code,拎到你hard code既client id同client secret。
拎到client id同secret,就有security位俾hacker利用。
玩法可能好多(e.g: phishing, 假client etc)。
實際security impact,視乎OAuth以至成個architecture﹑business flow擺位,以及token權力範圍。

其實就算做OAuth,都有較安全做法。
就係當mobile app install落部機時,立即dynamic registration去register一個per device既OAuth client。
reg完OAuth, 然後立刻將device client register到application的DB。
runtime時,device每次perform operation,都是以device名義去access server。
server side每次checking就要check token validity,同埋device authentication(對返DB record)。

consideration其實有幾個point不過skip費事太長氣。
淨係講最重要一點:

hacker就算crack左你個mobile app睇晒source code都冇用,因為每部device裝完機到runtime都會拎個dynamic client去,根本唔會有個hard code左既id/secret儲o係source code。

(其實玩 IoT 可能都係類似咁,起碼要有device registration, rather than only IoT app registration)

[Article sharing] A lesson for developers to revise on CSRF attack protection

Here is the article: Defense Against the Dark Arts: CSRF Attacks
This is a good article which telling a humor story about how to protect web application from CSRF (Cross-site request forgery) attack.
I think it is 120% worth for web app developers to read for 溫固知新, no matter you are frontend or backend developer.

I suggest to read the whole story, but for those TL;DR , I can share the summary here:

 

  1. Introduced an authentication system to prevent attackers from impersonating users.
  2. Used cookies to do this in a way that does not require two HTTP roundtrips (with a loading spinner in between) to view pages with private information, like a page listing a user’s private messages.
  3. Defended against <img src="some-endpoint-here"> GET CSRF attacks by requiring that endpoints which make changes to things use HTTP verbs other than GET. (In this case, we used POST.)
  4. Defended against <form> POST CSRF attacks by checking that the Origin and/or Referer headers match hogwarts.edu (and rejecting the request if neither header is present).
  5. Added a second line of defense against future potential Origin and/or Referer vulnerabilities by requiring that the Content-Type header be set to application/json.

 

Dear developers, have a nice day~!

stateful-result – nodejs module for represent operation result with status code

Nodejs stateful-result module

This module can be used for representing an operation(e.g: function return) result with a meaningful status code. By default, we suggest to make use of HTTP status code. Hence, code 200 for status of operation OK, and code 404 for status of operation target not found, etc.

Links

Github: https://github.com/airicyu/stateful-result
NPM: https://www.npmjs.com/package/stateful-result

Samples

Sample 1: Getting success result (code 200 OK)

console output

Description:

Simple enough, isn’t it?

Sample 2: Getting fail result (code 404 Not found)

console output

Description: The error object is an extended error object which has the “code” attribute. In this case, the code is 404.

Sample 3: Get result if success result or throw error if returning fail result (code 404 Not found)

console output

Description: This time we called method “getOrThrow”. If the result is success, the result would be returned as previous samples. If the result is fail, the error object would be thrown.

OpenAPI 3.0RC (Swagger’s next version) is out & highlight previews

Some background about Swagger & OpenAPI spec

Swagger is a kind of open REST API definition spec.
The Swagger specification development started in 2010. In 2015, Swagger is donated and renamed as OpenAPI Initiative under the Linux Foundation, in order to advance a common standard across industries. A number of tech companies, including Google, IBM, and Microsoft, signed on as founding members of the OpenAPI Initiative, and the Swagger Specification was rebranded as the Open API Specification.
Nowadays, OpenAPI-Spec 2.0 has become the most popular REST API definition spec. (Even more popular than RAML & API Blueprint)

 

OpenAPI-Spec 3.0 Release Candidate is out in Feb

In Feb 2017, OpenAPI-Spec 3.0 is currently out as release candidate and considered feature completed.

For the spec details, you may have a look at their Github:
https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/versions/3.0.md

I also found two blog articles which mentioned some highlight changes in 3.0:
http://nordicapis.com/whats-new-in-openapi-3-0/
https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/

 

Highlight Features Previews

I previewed some highlight changes about the Swagger 3.0. It has some pretty good support features which would definitely help on REST-API’s daily-life usages.

For example,
1) Introducing “examples” definitions, which allow defining examples for operation request/responses. (Lacking in 2.0)
2) Support defining multiple servers (instead of single host definition in 2.0)
3) Introducing “linking“, which for describing hypermedia (e.g: HATEOAS)

I think the “examples” object is a specially-great feature because:

1) Making API Friendly to Test-driven practices
People can leverage OpenAPI3 examples definitions to describe API example requests/responses.
Hence tools would be able to easily make API mockups/stubs for testings.
Hence, it may be more friendly to Test driven practices.

2) Better in API documentation with examples
In OpenAPI2, with Swagger-UI library, we can already use the API spec to generate a developer friendly Document UI page for REST APIs.
The OpenAPI3’s “examples” definition can be a complement part in the Swagger-UI to show example requests/responses, which is lacking in existing 2.0 version.

 

 

P.S. Below is the revision history of Swagger/Open API
Version Date Notes

Version Date Notes
3.0.0-rc0 2017-02-28 Implementer’s Draft of the 3.0 specification
2.0 2015-12-31 Donation of Swagger 2.0 to the Open API Initiative
2.0 2014-09-08 Release of Swagger 2.0
1.2 2014-03-14 Initial release of the formal document.
1.1 2012-08-22 Release of Swagger 1.1
1.0 2011-08-10 First release of the Swagger Specification

《異類僑居者》

幾年前睇過少少一本基督教書籍,叫《異類僑居者》(睇左1/3都冇)。

我個人粗淺理解其大意是說:
基督教信仰群體面對整個社會,不應為了輸出其信仰價值,而以信仰群體的力量去直接參與整個社會的各個社會議題。
原因是,當信仰群體直接把信仰價值訴諸各社會議題,其實同時亦無可避免沾上各種遊戲潛規則;
這不但影響信仰價值本身的正當性,同時也易令信仰迷失。

書中提倡的是:
現實社會中的人的當下是虛無的,而信仰群體的當下是在基督救贖的歷程中,兩者的timeline是不同的,而後者只是現實世界timeline中的僑居過客。
信仰群體應視自身為整個現實社會中的少數/異類僑居者。
面對外在社會,信仰群體不需要去直接主導整個社會的各個社會議題;而是求諸內﹑求諸踐行。
信仰群體在群體內透過信仰的力量互相支持,建立community,從而在community內踐行信仰價值。

其根本思想雖然表面上是很平和﹑是求諸內,但其概念上以信仰為群體依歸,超越種族﹑國家﹑制度,其實是一種很具顛覆性的主張。

但問心,其實有D想法都係太過離地/理想主義。
但又咁講,信仰依D野有時就係咁樣。要apply for all cases可能唔太realistic,但o係個別某D情況既context去apply,又唔係冇可能。

——————————————————————

當想到香港社會時,我諗起過這本書的想法。
但人人不盡相同的信念,未必能像信仰一樣有如此大內聚力,community的想法很難實現。

有時當想到一些商業公司文化/policy問題時,我都可能會諗起這本書的想法。
但當同樣的問題套用到商業公司模式中,往往就因為缺乏了信仰/信念/理念在其中內聚,所以難以Form到一個community。
最後也就變成了「上有政策,下有對策」或各種山頭主義。

一些寫library的practices分享

我寫library/module通常有一d practices。

1) 我多數是將data store的底層abstract。
並且default使用memory data store。(e.g:用個hashmap儲住就算)

我咁做唔係因為懶/求奇。
而係因為我自己作為developer理念係minimum-viable就是最簡單,就是最好。
面向developer,其實最好就係用最快最簡單最少step方法就可以俾developer taste得到。
default使用memory data store,就至少唔駛setup database。

但我通常亦都會留位俾developer去switch用其他data store implementation。
我通常都會另外做一個堅database data store implementation 俾佢next step即刻可以switch到。
最近寫的code,我有時會再另外再做一個remote REST resource data store implementation。

2) 我多數都會做埋self contain的minimum-runnable helloworld samples。
我擺上github果堆library,我都一定會寫埋readme Document。
但developer好多時同時好需要sample as a reference去抄抄貼貼黎用,會快過佢地自己齋對住readme doc/API doc黎由零砌起。
砌一d minimum-runnable helloworld samples,佢可以踢著黎試/trace/改code黎自己去研究點玩點用。

3) Document, test case, 依d基本野唔駛講。

Visual Studio Code Rest client extensions

Visual Studio Code Rest client extensions , 是我用開 Visual Studio Code 寫 code 時的一個好常用/adapt的feature。
” Rest client ” extensions其實就好似 Postman (一個chrome extension,用黎mock up去send HTTP request做testing)。
但佢就再簡化d,唔需要UI,而係用text就夠。
即係例如我隨便一個file入面有呢幾行字:

然後我select呢段字,禁ctrl+alt+r,就會mock up send左個request出去,再有一個tab show response (as text),如下:

這個好處是,我能夠用一個text file就儲存好一堆mockup testing request。
需要更改時直接改內容就好。
測試時,也不用import/export到postman,並且不用離開IDE就能直接測試endpoint。