詢問跨站存取


#1

想要詢問跨站存取

分為2個部分

一個是跨網域存取資料進來

一個是跨網域傳送資料出去

原本沒有資訊安全只是一般訊息AJAX傳遞也就算了

但是有一個奇怪的小CASE 細想之後 牽扯到跨站 跨語言 使用者帳密安全


跨站存取資料 JSONP CORS

基本上我看了看基本上還是HTML 配合JS再做處理

但是這種做法 跨站會安全嗎

涉及帳密 以及金錢 我怎想都不對啊

是否還需要其他安全措施比較好?

像之前所提的 API 或是SSL 等措施

原本是提及 只需要傳送金流相關字串 結果講到後面 連使用者訊息也要

但使用者訊息傳送出去 在其他的網域也必須要接收到 但過程並沒有要給使用者另外做CURD的工作

所以想上來詢問有沒有比較清晰的看法


真的要說 其實有點像跨站接收金流傳遞過來的中介中心的概念

而中介中心 需要接收來至不同地方的傳送 或是資源共享


#2

嗯,你整個思維反了 … 且基本上沒帳密安全問題,單純多個步驟即可

主因是如果用 JSONP 應該都會額外用 cookie 來做 session,類似

A 來源站 , U 使用者 , B 對象站

A : session : user_id = 123 (已登入)
A > U > B (A 包裹一個網址讓 U 能到 B 去,可能用 GET 即可)
A 指定 B 的網址內有 session token,B 回傳 success 時順便 set-cookie
B : session : user_id = 123

其中 set-cookie 段作用在『回傳給你資訊的來源 domain 上』,所以 A 只需要把 token 過給 B 一次水,A / B 都會知道目前這個使用者是誰,這樣就沒有帳密問題之類的,因為過的是 token 而非帳密,而 session token 可以用 server to server 的方式來做確認(B <=> A),很像 OAuth2 的解法就是(U = 使用者,三個流向完成換 key : A > U > B , B > U > A , A <=> B)

再來,SSL 能保證『內容』和『網址』不外流,這是大前提,且是 spec 請牢記,否則你會有被害妄想症,所以網址內可以塞一票鬼東西都沒事的,不過這邊盡量用 POST(要寫 origin …),如果用 GET 要注意會被重新整理來重複執行

最後,用 checksum 之類的東西防止被『使用者自己』竄改,就是 B 那邊要另外 verify 過即可

然而很多金流都不管這些,所以單純的把需求全委派到對方那邊去,類似轉頁或是 iframe 之類的,也就沒有 A / B 之間的溝通的問題了唄,這是最簡單最單純的解法就是了,所以國內大都是這種||

如果你的 domain name 太多,類似給第三方服務,通常 origin 都會是 * 這種 wild card,不過這種弄在站內服務大都會被攻擊唄,所以乾脆不寫,然後用 JSONP 反而會好點之類的


#3

主要是碰到一個奇耙的問題

有個a廠商 他專門幫某教育機構做資訊服務

但是教育機構大到某種程度 其實就很像政府機關 啥都委外

然後a廠商也藉機各種資訊綁架 金流資料 資源服務 網站等等 通通被架在外頭

教育機構連產出一個 歷史的交易資料都沒有 完全被a廠商綁架到爽

金流要給多少給教育機構也是a廠商說得算 被汙了多少錢根本沒人知道 (超扯 這樣的廠商也能生存)

所以 現在要分開處理 一段一段的去處理 首先最重要的就是 金流 還有一些教育機構的資料共享

前端的網站漂漂亮亮的 後端多一個中介平台來處理 讓一些資料可以回流到教育機構 他們可以查詢到

但是真的機車的是 最好有人是這樣處理

如果在同網域中同個地方 我就用基本的頁面跳轉就可以解決

但現在是完全要跳脫思考

1.會不會做完被a廠商惡意網路攻擊(據說有前例)

2.前端網站是架設在獨立在某個地方 跟後端得中介平台完全不一樣的地方

3.不要指望他們可以技術配合 我必須自己去模擬前端 傳送或是資訊交換到 完全獨立的資訊中介平台
當作完後我也必須把相關前台使用方式資料給a廠商 a廠商不得已也要自己去處理
(避免用一些爛透的說法 不同語言不能做 或是 某某原因不可以)

4.既然叫中介平台也不可能再讓使用者在輸入一次帳號資訊 只能透過傳遞的方式來處理

原本想說沒很複雜 但是a廠商各種鬼扯 讓問題本身複雜化
(馬的想賺點外快就碰到地雷股)


Ok~以上是前因 就我所知 a廠商 網站用 php laravel 寫出來

但傳遞這東西感覺主因還是前端html與js來處理過程 跟語言不太會扯上關西

所以 為何我的思考邏輯會感覺上是相反的 其實是因為前面說的原因 :sob:

目前想說先使用 token 過水 JSONP 來實作這一塊 ssl 保護不外流 也不知道這樣夠不夠…

最可恨的是後面我還要把a廠商的其他東西整合進來 那又是另一塊坑了…


#4

我建議你想事情的時候,先把東西分離,什麼是 spec,也就是無法改變的規定,然後才是你想要的解法

看到對這題只能和你說:那就去 Hack 他啊!! X"DD

你可以完整模擬溝通封包,或是這年頭才有的邪惡工具 phantomjs => chrome handless mode (後者有人包成整個 docker 了…)
可以『完整模擬』整個瀏覽器,包括所有 AJAX 全都正確( 因為就是一個沒介面的瀏覽器 X"DD,AJAX 從前都是硬傷,但現在開始都不是…),所以除了 Captcha 沒辦法破外其他都無法辨識

然而這邊有趣的地方在於,你可以把 Captcha 轉嫁給使用者即可,左手拉右手雙方過個水, Captcha 讓使用者自己輸入就可以破解了…

所以其他自幹,CORS / JSON vs JSONP 所有的鬼議題都只在『一般環境下』有效,你自己打個中介的 bot 就可完全繞過之類的,&我最愛這種技術不肯配合或是人力不足的公司,代表他們的 code 永遠不會更新,所以修 code 次數也會降低之類的

so~ 以上給你參考,腦袋轉個彎就能海闊天空,如果對方是簽約公司或是認識的,大可以直接 Hack(但是要沒有道德爭議的使用下),通常過個類似自幹的 proxy 就可以做到這類的事情哩


#5

突然覺得 這個想法到既邪惡又有效~~~

我怎沒想到這種方式

傳遞過程只要開個小洞 Hack 資料過來 其他我自己處理即可

既然無法配合 他們還可以在更簡化一輪 把跳轉頁面連過來就好 其他不用他們去弄了

其他的安全方式 我就直接弄一弄 反正資料已經過來 剩下就我自己去搞就好

也省一堆事情

太感謝jc大了:joy:


#6

中午吃飯時間去翻一下 phantomjs 的相關資料

這個東西真的是好邪惡阿 居然有這種東西存在

畢竟沒做過 我大概想一下執行流程

a網站 => www.aaa.com.tw

b中介網站 => www.bbb.com.tw

a網站 我直接在開發者模式下 該頁面找他的送出的的位置 www.aaa.com.tw 自己手動改成 www.bbb.com.tw

然後跳轉至b網頁後 直接用 phantomjs Hack 他到底傳了啥東西 格式有啥

當然中間需要過個水 以免有人再無腦攻擊

然後拿到資料後看是要做log還是單純跳轉動作又或者保存成 sesson 進入一個進階選擇的使用介面

後面就有這些資料後就可以自己看著辦要怎樣 看要做金流的帳務或是歷史報表又或者是依些資源使用…等等

之後完成之後 只要請a網站的編輯者 直接把原始連結導向 b中介網站 其他都不用a網站去傷腦筋

不知道使用邏輯上這樣是否正確~~~??


#7

其實可以不要用 phantomjs 就不要用唄,因為那個東西會開一個真的瀏覽器出來,所以對記憶體之類的都是硬傷

中介網站用類似 sinatra 的東西就可以做了,類似用 RestCelint 來做封包破解,東西弄完後才從 sinatra 那邊丟回給使用者之類的?


#8

sinatra應該是rails的一種簡化版的架構吧~??

我還要考慮到後續 教育機構那邊如果覺得可以 要一口氣往前端服務一起整合 我是必須要一個比較完整的 framework

如果真的只做中介用途 sinatra 也許是個好的選擇

又或者是拿 sinatra 真的當一個純粹的中介用途 前端之後再拿rails的framework來使用

這樣子好像也不錯???


#9

沒,單純 Sinatra 很簡單很小很好寫,所以拿來做概念的測試實現應該最快,寫好後再丟給 Rails 也可以,不過看你的需求唄,and 你應該去嘗試寫看看,有實際問題再丟來哩,而不是單純的只在腦袋裡面轉之類的


#10

好的 我正在玩

這些真的是一個邪惡的東西

require 'sinatra’
require 'rest-client’
get ‘/’ do
RestClient.get(‘https://www.blogger.com/about/?hl=zh-TW’, headers={})
end

直接看到所有的拋接流程(驚呆了) 我先花個幾天玩熟一點再來想後面 先搞清楚它比較詳盡的用法

不然一直空想也不對 一直鬼打牆也不是很好

未知玩具會一直亂勾想法

先謝過JC大了 這是一個新大陸阿~~~