Web services API design suggestion ???

Trước khi chuẩn bị design một web services API langxang đã đọc và tham khảo rất nhiều resources trên net. Mục đích muốn focus vào RESTful hơn là SOAP nhưng vấn đề nan giải nhất là security. Mới thử một suggestion nhưng vẫn còn nhiều chuyện phải nghĩ ... nói chung chẳng có gì hoàn hảo cả, chắc phải nghĩ vậy thôi.

Mình đã từng đọc đâu đó trên InfoQ câu này
REST is simple. Applying Enterprise-class Security is not.

1. Giới thiệu

Web services và format support

Tạo một bộ RESTful web services hỗ trợ XML và JSON qua HTTP.

Cơ chế authenticate và authorization

Các yếu tố cần suy nghĩ đến là user experience UX^[1], OpenID support (federate-authentication) cũng như resources trong thời điểm hiện tại.

Yêu cầu đặt ra là một cơ chế flexible, lightweight. Tất nhiên không thể tốt hoàn toàn nhưng cần đạt mức chấp nhận được (về security, thời gian thực hiện ...).

Suggestion là một mô hình dạng token signing lấy ý tưởng từ Flickr API (thay vì dùng OAuth). Trong thời gian tới sẽ cố gắng hoàn thiện hệ thống API, có thể thực hiện support OAuth trong thời gian tới.

Các thành phần cần thực hiện

1. Thiết kế và định nghĩa các APIs.
2. Server viết bằng PHP thực hiện các chức năng: đăng ký API key, xử lý authenticate, xử lý authorization và RESTful request.
3. Library C# SDK wrap các API
4. Library PHP SDK wrap các API (optional)

2. Cơ chế authenticate và authorization (tham khảo Flickr Authentication API^[3])

Authentication prerequisites

Tất cả các ứng dụng muốn sự dụng Authenticate API phải đăng ký một API key (đáp ứng yêu cầu có thể monitor ứng dụng) và phải thiết lập các thông số sau để có thể có API key

1. Application title
2. Application description
3. Application logo graphic (optional)
4. Application ’about’ URL (for example application introduction and download, optional)

Authentication methods

Sau khi đăng ký API key, ứng dụng sẽ được cung cấp secret key dùng trong quá trình signing (signing request process). Ứng dụng sẽ chọn 1 trong 2 methods chứng thực – web based hoặc non-web based.

Hiện tại sẽ support dạng non-web based authentication. Tương lai sẽ mở rộng hỗ trợ 3 loại như sau: web based authentication, non-web base authentication và mobile authentication.

3. Authentication dành cho non-web based application

Hiện tại Flickr sử dụng message digest algorithms MD5^[7] theo đó desktop và non-web based application sẽ thực hiện giao tiếp với server để nhận được token. Tuy nhiên với những hạn chế của message digest algorithms MD5 có thể phải thay đổi so với cách thực hiện của Flickr^{[4] [5] [6]}. Chi tiết xem phần signing process.

Đầu tiên desktop application thực hiện gọi API method auth.getFrob, method này yêu cầu signing (xem phần thực hiện signing). Nếu thành công method sẽ response một ‘frob’, dùng để construct một URL cho phép user thực hiện đăng nhập (launch system’s default browser) http://www.company.com/services/auth/?api_key=[api_key]&perms=[perms]&frob=[frob]&api_sig=[api_sig]

API signature là kết quả của signing process.

Permission yêu cầu user thực hiện grant, đối với trường hợp hiện tại chúng ta có thể omit. Đối với user log in vào system sẽ thực hiện cấp quyền tương ứng với user đó (yêu cầu làm rõ chức năng và cách xử lý của server).

Như vậy URL thực hiện authenticate là:

http://www.company.com/services/auth/?api_key=[api_key]&frob=[frob]&api_sig=[api_sig]

Hệ thống sẽ yêu cầu user log in với username/password hay OpenID. Tên application và mô tả của application sẽ được hiển thị (trong trường hợp quyết định permission theo role sau khi đăng nhập không cần hiển thị permissions mà ứng dụng mong muốn có). Nếu user đăng nhập thành công thay vì redirect về callback URL như web application, system sẽ hiển thị thông báo user log in thành công và hướng dẫn quay về application (và có thể close trang thông báo này).

Sau khi user thực hiện chứng thực thành công, quay lại application để báo cho application biết đã xong quá trình chứng thực. Application cần thực hiện gọi API method auth.getToken bằng cách cung cấp api_key và frob (method này yêu cầu signing, xem phần thực hiện signing).

Response sẽ bao gồm authentication token cần thực hiện các API call sau này (các thông tin khác kèm theo ví dụ summary của user profile, yêu cầu làm rõ sau).

Renewing non-web based authentication tokens

Để kiểm tra cần renewing hay có đủ permission hay không, application cần thực hiện gọi auth.checkToken. Nếu token không hợp lệ hoặc không đủ permission, application cần yêu cầu một token mới giống như các bước yêu cầu token đầu tiên.

Implementation guidelines

User profile data (bao gồm auth tokens) nên được lưu lại tại local user's 'profile', theo đó có thể cho phép switch user với cơ chế multiple profiles/users mà không thực hiện sharing auth data. Trong môi trường Windows có thể thực hiện dựa vào registry trong phần HKEY_CURRENT_USER, hay trong user's home directory đối với OSX/Unix.

Users phải được cung cấp chức năng 'logout'.

4. Authentication permissions

Application không nên yêu cầu quyền cao hơn mức cần thiết phải sử dụng. Cụ thể trong trường hợp này không quan tâm đến việc request permissions mà permissions sẽ được cung cấp tùy theo loged in user.

Cụ thể có 3 level cơ bản như sau (xem xét chỉnh sửa nếu cần thiết):

• read - permission cho phép read private information
• write - permission cho phép thêm, sửa và xóa metadata (bao gồm permission 'read')
• delete - permission cho phép delete thông tin (bao gồm 'write' và 'read')

5. Authentication tokens

Mỗi authentication token được chỉ định riêng cho một user và một application tương ứng với application's api key, và chỉ được dùng tương ứng với application key này. Application có thể kiểm tra tình trạng của auth token bằng cách thực hiện API method auth.checkToken, method sẽ return tính hợp lệ của token cùng với user đã thực hiện authenticated (và permissions tương ứng nếu cần).

Authentication tokens có thể được thiết lập thời gian expire bởi user khi user thực hiện chứng thực với hệ thống. Chức năng này là chức năng nâng cao (có thể hide by default), có thể có 2 options là theo hour (1 hour) hoặc never. Chỉ duy nhất một auth token/app/user valid tại bất kỳ thời điểm nào. Application phải có trách nhiệm xử lý khi auth token expired, invalid và thực hiện renew.

Tất cả các API calls sử dụng auth token phải được signed (xem signing process).

6. Authentication frobs

Mỗi authentication frob sẽ tương ứng với một user và một application’s API key và chỉ có thể được sử dụng bởi application có API key này.

Giá trị của application frobs chỉ hợp lệ trong vòng 60 phút kể từ khi được tạo hoặc cho đến khi application thực hiện gọi auth.getToken.

Chỉ một application frob tương ứng với một application và một user được coi là hợp lệ tại bất kỳ thời điểm nào. Application phải có trách nhiệm xử lý khi auth token expired, invalid và thực hiện renew.

7. Signing

Tất cả các API call sử dụng auth token phải được ký tên (signed). Ngoài ra khi thực hiện các method auth.* methods và khi thực hiện chuyển hướng (redirections) tới trang chứng thực của hệ thống (system’s auth page) các yêu cầu này cũng phải thực hiện signing.

Như đã đề cập về hạn chế của message digest algorithms đặc biệt là MD5 hash, quá trình signing sẽ thực hiện khác với Flickr.

Các hướng có thể thực hiện là keep auth token secret bằng SSL, dùng auth token để signing hay coi auth token như là password bằng cách sử dụng HTTP digest authentication (RFC2617).

Một giải pháp khả thi là sử dụng một secure MAC implementations như HMAC-SHA1^[8] (được hỗ trợ bởi hầu hết các programming language kể cả client và server side). Key của HMAC-SHA1 có thể sử dụng là shared secret.

Quá trình signing thực hiện theo các bước như sau:

1. Thực hiện tạo danh sách các đối số thực (argument list) và sắp xếp theo alphabetical order dựa theo tên của tham số parameter name của từng argument. Có thể cần sẽ thực hiện normalize parameter (sẽ hướng dẫn cụ thể tham khảo Amazon Web Service, OAuth)

Ví dụ: foo = 1, bar = 2, baz = 3 sẽ được sắp xếp thành bar = 2, baz = 3, foo = 1

2. Concatenate shared secret với các cặp argument dạng name/value (argument name/value pairs). Ví dụ: shared secret là BANANA concatenated argument list string là bar=2&baz=3&foo=1. Dùng shared secret BANANA làm key của HMAC. Kết quả có thể có format dạng base64 hoặc hexa string. Ví dụ: kết quả signature với giả sử format là base64 như sau Dcpc3Uf85y1VvZFs276KvGtum5Q=
3. Append kết quả này vào argument list với parameter name là api_sig

Ví dụ: api_sig= Dcpc3Uf85y1VvZFs276KvGtum5Q=

8. Example cho non-web based application

1. User nhấn login button trên application
2. Application gọi background call tới server để nhận frob, call auth.getFrob ví dụ như sau http://www.company.com/services/rest/?method=auth.getFrob&api_key=987654321&api_sig=Dcpc3Uf85y1VvZFs276KvGtum5Q=
3. System return frob ‘1a2b3c4d5e’
4. Application launch system’s default browser với URL tạo được từ frob như sau http://www.company.com/services/auth/?api_key=987654321 &frob=1a2b3c4d5e&api_sig= Cdpc3Uf85y1VvZFs276KvGtum5Q=
5. Nếu user chưa loged in vào web site, user sẽ được hỏi có thực hiện log in hay không.

· User có thể đăng nhập bằng log in form(username/password)

· User có thể chọn đăng nhập bằng OpenID,khi đó sẽ thực hiện theo flow authentication bằng OpenID

6. Sau khi đăng nhập thành công user sẽ được hỏi có cho phép ứng dụng sử dụng các thông tin private hay không (trong trường hợp ứng dụng cụ thể thì private data là gì cần định nghĩa rõ)
7. User chọn ‘Yes’ web site sẽ update auth database.
8. User được hướng dẫn quay lại application và có thể đóng web page.
9. User quay lại application và nhấn button ‘Continue’ (nút log in button trong bước log in có thể chuyển thành continue button)
10. Application thực hiện background call tới auth.getToken, ví dụ http://www.company.com/services/rest/?method=auth.getToken&api_key=987654321&frob=1a2b3c4d5e&api_sig= Depc3Uf85y1VvZFs276KvGtum5Q=
11. System trả về auth token ‘9765984’
12. Application có thể thực hiện các background API call với auth token (signing với key là shared secret) ví dụ http://www.company.com/services/rest/?method=user.getProfile&api_token= 9765984&api_sig= Efpc3Uf85y1VvZFs276KvGtum5Q=

9. References

[1] UX research on Desktop Apps using federated login and/or OAuth

http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps

[2] The OAuth Core 1.0 Protocol

http://tools.ietf.org/html/draft-hammer-oauth-08

[3] Flickr Authentication API Spec

http://www.flickr.com/services/api/auth.spec.html

[4] Flickr API Authentication Hash Extension Attack

http://www.securiteam.com/securitynews/6J0042APPS.html

[5] Flickr's API Signature Forgery Vulnerability

http://netifera.com/research/

[6] Of the use of standards: a look at the Flickr API authentication mechanism

http://larve.net/people/hugo/2005/blog/2006/01/08/of-the-use-of-standards-a-look-at-the-flickr-api-authentication-mechanism/

[7] RFC 1321: The MD5 Message-Digest Algorithm. RSA Data Security, Inc., April 1992

http://www.ietf.org/rfc/rfc1321.txt

http://en.wikipedia.org/wiki/MD5

[8] RFC 2104 HMAC: Keyed-Hashing for Message Authentication, February 1997

http://www.ietf.org/rfc/rfc2104.txt

http://en.wikipedia.org/wiki/HMAC

Just fight for your life ...

People say "Programming is for fun, not for money" and many people get in programming with this idea. Sometimes I have the same thought but is it really true? Programming is neither inherently fun or not fun. Career path, the lack of a programming-centric. I can't work for a little of money or work without any of the potential benefits.

Faster, better, cheaper but how... Almost programs you developed are incomplete softwares, just-runable things. Even you don't know what they are. So you develop/create what or you're just forced to write something you don't like. Really fun?

Many companies think the good way to encourage smart developers is moving them elsewhere, 'moving into management'. New opportunities, new challenges? Maybe. But I don't think experienced developers really want to move into management. Developers do that because they feel a lot of pressure while companies often don't know what to do with their developers. And the most stupid thing about this is a really good developer is worth far more than any low or middle level manager.

All fool things, I won't care. Now I'll looking for really exciting programs and enjoy lots of new thing. Try to get enough money with bored job. Professional programming is a profession and has its good points and bad points. So fight for your fun...

Sử dụng Detours để tìm lua_State cho AutoPlay

Bài viết mô tả việc dùng Detours

Software package for re-routing Win32 APIs underneath applications. Under commercial release for over 10 years, Detours is licensed by over 100 ISVs and used within nearly every product team at Microsoft.

để thực hiện API hooking, cụ thể là ReAlloc nhằm lấy được base address của lua_State dùng cho AutoPlay. Lý do để thực hiện việc này là không thể dò lua_State bằng cách thông thường dùng CheatEngine (xem lại bài Sử dụng Cheat Engine để search base address dùng cho auto play).

Bài viết này không đi sâu chi tiết vào Detours, chỉ mô tả cách sử dụng Detours trong trường hợp ko dùng được CheatEngine. Cách thực hiện này có thể áp dụng trong các trường hợp có logic tương tự.

Do mấy bữa nay bận nên không thể ngồi dò base address của lua_State nên không sửa hoàn chỉnh cái auto Tru Tiên. Hôm nay cuối tuần mình sẽ ngồi viết tutorial cho phần này. Sau này nếu có ai muốn tìm giá trị của lua_State hay những địa chỉ trong trường hợp tương tự thì vẫn biết đường mà mò.

Build Lua library

Đầu tiên mình check phiên bản Lua mà game đang sử dụng (là 5.1.1), sau đó phải kiếm 1 bản lua về tại http://www.lua.org/download.html. Bản mới nhất hiện tại là 5.1.4, có thể dùng bản này hoặc 5.1.1. Sau khi download về và extract trong 1 folder Lua-5.1.1. Sau đó tạo một project static library Lua-5.1.1.vcproj, add các files trong thư mục src (nhớ bỏ 2 file lua.c và luac.c là 2 files build lua command line) vào project.

Mục đích là build static library Lua. Có thể tạo solution riêng để build lua library 1 lần thôi.

Sau khi build xong có lua-5.1.1d.lib và lua-5.1.1.lib, có thể copy lên thư mục Lib để dễ reference.

Cách thức cấp phát lua_State

Tạo một project đơn giản dạng Win32 application (dùng cái này khỏi dính dáng đến MFC) để biết lua_State được cấp phát như thế nào. Tạo Win32 application viết dạng Dialog

// Test.cpp : Defines the entry point for the application.

#include "stdafx.h"

// Header for Lua library
extern "C" {
#include "../Lib/Lua-5.1.1/src/lua.h"
#include "../Lib/Lua-5.1.1/src/lauxlib.h"
#include "../Lib/Lua-5.1.1/src/lualib.h"
};

// 21/Nov/2009 fixed link to Lua library
#if defined(_DEBUG)
// Debug libraries
#pragma comment(lib, "../Lib/lua-5.1.1d.lib")
#else
// Release libraries
#pragma comment(lib, "../Lib/lua-5.1.1.lib")
#endif

HINSTANCE g_hInstance = NULL;
BOOL CALLBACK DialogProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);

int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
 LPSTR lpCmdLine, int nCmdShow)
{
  // TODO: Place code here.
    g_hInstance = hInstance;
 
    HWND hDialog = 0; 
    hDialog = ::CreateDialog(hInstance, MAKEINTRESOURCE(IDD_TEST_DLG), 0, DialogProc); 
    if (!hDialog)
    {
  LPVOID lpBuffer;
  ::FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
   NULL, GetLastError(), 0, (LPTSTR)&lpBuffer, 0, NULL);

        ::MessageBox(NULL, (LPTSTR)lpBuffer, _T("CreateDialog"), MB_ICONEXCLAMATION | MB_OK);
  ::LocalFree(lpBuffer);

        return 1;
    } else {
  ::ShowWindow(hDialog, nCmdShow);
 }
 
    MSG  msg;
    int status;
    while ((status = ::GetMessage(&msg, 0, 0, 0)) != 0) {
        if (status == -1) {
            return -1;
  }

        if (!::IsDialogMessage(hDialog, & msg)) {
            ::TranslateMessage( & msg );
            ::DispatchMessage( & msg );
        }
    }
 
    return msg.wParam;
}

BOOL CALLBACK DialogProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
 WORD wId, wEvent;
 HICON hIcon = NULL;
 lua_State* state = NULL;
 TCHAR buffer[1024] = { '\0' };

    switch (message)
    {
    case WM_INITDIALOG:   
  hIcon = ::LoadIcon(g_hInstance, MAKEINTRESOURCE(IDI_ICON));
  if(hIcon) {
   ::SendMessage(hWnd, WM_SETICON, (WPARAM)ICON_SMALL, (LPARAM)hIcon);
  }
        return TRUE;

    case WM_COMMAND:
        wId    = LOWORD(wParam); 
  wEvent = HIWORD(wParam); 

  // Parse the menu selections:
  switch (wId)
  {
   case IDC_BUTTON_TEST:
    state = luaL_newstate();
    wsprintf(buffer, _T("[Process %p] "), ::GetCurrentProcessId(), state);
    ::MessageBox(NULL, buffer, _T("Test"), MB_OK);

    if (state != NULL) {
     lua_close(state);
    }
    
    break;

   case IDOK:
    ::DestroyWindow(hWnd);
    break;

   case IDCANCEL:
    ::DestroyWindow(hWnd);
    break;

   default:
    return ::DefWindowProc(hWnd, message, wParam, lParam);
  }
        return TRUE;

    case WM_DESTROY:
        ::PostQuitMessage(0);
        return TRUE;

    case WM_CLOSE:
        ::DestroyWindow(hWnd);
        return TRUE;
    }
    return FALSE;
}

Test project đơn giản chỉ là một dialog có một nút test.

// Header for Lua library
extern "C" {
#include "../Lib/Lua-5.1.1/src/lua.h"
#include "../Lib/Lua-5.1.1/src/lauxlib.h"
#include "../Lib/Lua-5.1.1/src/lualib.h"
};

//  21/Nov/2009 fixed link to Lua library
#if defined(_DEBUG)
// Debug libraries
#pragma comment(lib, "../Lib/lua-5.1.1d.lib")
#else
// Release libraries
#pragma comment(lib, "../Lib/lua-5.1.1.lib")
#endif

File lua-5.1.1d.lib là Lua đã build trong bước trước.

Khi thực hiện nhấn button Test sẽ tạo một lua_State, do đó để break point ngay đây xem có được thông tin gì không. Mình biết lua_State được tạo bởi luaL_newstate.

// Parse the menu selections:
switch (wId)
{
 case IDC_BUTTON_TEST:
  state = luaL_newstate();

Thực hiện F11 step into sẽ vào lua_newstate xem tiếp

LUALIB_API lua_State *luaL_newstate (void) {
  lua_State *L = lua_newstate(l_alloc, NULL);
  if (L) lua_atpanic(L, &panic);
  return L;
}

Tiếp tục step into lua_newstate với l_alloc

LUA_API lua_State *lua_newstate (lua_Alloc f, void *ud) {
  int i;
  lua_State *L;
  global_State *g;
  void *l = (*f)(ud, NULL, 0, state_size(LG));
  if (l == NULL) return NULL;

Mình để ý tiếp lua_Alloc và step into lua_Alloc f (line 5), step into lua_Alloc tại bước này

static void *l_alloc (void *ud, void *ptr, size_t osize, size_t nsize) {
  (void)ud;
  (void)osize;
  if (nsize == 0) {
    free(ptr);
    return NULL;
  }
  else
    return realloc(ptr, nsize);
}

Tới đây mình hầu như đã có thông tin mong muốn

• Lua alloc sử dụng API realloc
• Kích thước cấp phát là nzine

Có nghĩa là lua_State là giá trị trả về của realloc với size là 376. Con số này rất quan trọng mình sẽ ghi nhớ.