python接收wss請求

⑴ 電子口岸埠61231開啟wss服務啟動失敗

解決方法：一般情況下是java進程還在運行導致的。啟動任務管理器,在進程裡面把java.exe和javaw.exe的程序全部殺掉即可。
1.前提是直接ws服務可以起來，但是wss用自己簽的證書就不行的前提下

2.在瀏覽器設置允許從本機使用不安全證書

自己生成的證書，沒有經過驗證，jdk不認可

• 啟動伺服器

• 使用SSLCre請求生成一個jssecacerts

• 將jssecacerts替換成D:Program FilesJavajdk1.8.0_171jrelibsecurity下的cacerts

• 要記得改名字 。

⑵ greaterwms是什麼

GreaterWMS，是一款免費開源的倉庫管理軟體。
前端使用Quasar Framework框架，後端為python，100萬種API組合，可以支持任何業務二次開發。
由於未來會加入深度學習，所以後端使用Python作為開發語言，啟用Django作為後端框架，Django-Rest-Framework作為API開發框架，能更加方便用戶開發出屬於自己的系統。
前端使用Quasar Framework，高性能前端框架，基礎是VUE.JS。

⑶ python的內建函數跟庫函數的區別

【區別】：
標准庫函數都需要import xxx才能取得。
內建函數都在__builtins__裡面，在global里直接就能用。
【補充】：
1.python中，我們可以通過對內建的比較函數進行自定義，來實現運算符重載。
我們常用的比較運算符有
大於 > 對應的內建比較函數為 __gt__()
大於等於 >= 對應的內建比較函數為 __ge__()
等於 == 對應的內建比較函數為 __eq__()
小於 < 對應的內建比較函數為 __lt__()
小於等於 <= 對應的內建比較函數為 __le__()
2.庫函數（Library function）是把函數放到庫里，供別人使用的一種方式。.方法是把一些常用到的函數編完放到一個文件里，供不同的人進行調用。調用的時候把它所在的文件名用#include<>加到裡面就可以了。一般是放到lib文件里的。
【參考資料】：
http://wenku..com/link?url=JK3KWVBlVn38OsxJBnzmKO-_

⑷ wss 請求的伺服器需要安裝什麼證書

強制瀏覽器伺服器證書，具體的做法就是在瀏覽器的安全選項中添加例外，將伺服器的ip地址

⑸ 請問各位大大，Python如何編寫websocket的服務端和客戶端，wss的那種

自己開發websocket的服務端和客戶端不是不可以，就是短時間內難以做出來穩定性高的服務。

如果真要自己開發也不是不行，python下可以用的websocket或者channels來開發websocket，具體如何實現你網路一下就有很多教程了。

不過如果是在商業項目中運用的話，穩定性、高並發性是需要著重考慮的，可以嘗試下第三方的websocket推送服務的。

我們項目現在集成的是【GoEasy】websocket推送，目前使用良好，穩定性這些都不錯。

⑹ python openpyxl 切片單獨一行、一列出錯

如圖所示

⑺ 如何全面掌控session

WebSockets是一個能夠給單TCP連接提供全雙工信道的HTML5特性。它的持續性連接功能，使得構建B/S模式的實時應用成為可能。Websockets常常用在那些帶有聊天功能的WEB應用上。

下面的圖片就非常貼切地闡釋了一個APT攻擊用到的websockets：

科普：

同源策略(Same origin policy)：同源是指，域名，協議，埠相同，即瀏覽器會檢查同一瀏覽器的不同選項卡中，來源相同的腳本才能跨選項卡執行。

Origin欄位：瀏覽器在發送POST請求的時候可能會加上一個Origin欄位，這個Origin欄位主要是用來標識出最初請求是從哪裡發起的。如果瀏覽器不能確定源在哪裡，那麼在發送的請求裡面Origin欄位的值就為空。

IronWASP：某開源WEB測試平台，用戶可以自定義安全掃描，並且可以自己用python/ruby來定義插件系統。相關介紹見：http://www.freebuf.com/tools/32948.html

ZAP(Zed Attack Proxy)：是一款集成各種工具的滲透測試框架，可以發現在WEB應用程序中的漏洞，相關介紹見：http://www.freebuf.com/tools/5427.html

WebSocket的安全評估

最近，我們對一個擁有復雜菜單選項和功能的WEB應用做了安全評估。該應用中大部分操作都用到了web-sockets，這意味著其大多數行為都不會記錄到http代理日誌上。

首先，我們打開主頁後，網站會載入一個帶有JS腳本和CSS文件的靜態網頁。此後，整個通信交互會轉為Websockets模式，瀏覽器和服務端之間會建立websocket連接，從而載入網站里所有可見的HTML資源。點擊鏈接或者提交Form表單時，瀏覽器會向服務端發送一些WebSocket消息。伺服器處理了這些消息後，會通過WebSocket進行反饋，而後客戶端瀏覽器會展示新的HTML內容。

這時當websocket消息在進行交互時，通信數量是非常巨大的。每隔一秒它們之間會有心跳探測包的交互。然而現有的工具達不到我的要求，我不得不給IronWASP添加了一個Websocket消息分析裝置和一個WebSocket客戶端，這樣它才能識別Websocket從而嘗試fuzz其漏洞。你可以在在這里了解下相關知識。

在測試這個應用時，我發現它存在WebSocket跨站劫持(Cross-Site WebSocket
Hijacking)漏洞(由christian
schneider首創)。當然，我會在給大家介紹測試方法之前，解釋下這個漏洞的影響。在測試相關Websockets應用之前，我們需要先做下准備。

WebSocket跨站劫持漏洞實驗准備

大家應該明白，同源策略(SOP)不會通過瀏覽器在websockets上強制執行(同一瀏覽器下，受SSL保護的頁面，不會讓非SSL的WebSocket通過)，我們測試的應用採用了http
cookie作為session認證，WebSocket通過瀏覽器發送的消息不會有Session ID或是隨機參數。

這樣一來，如果某用戶登錄了帶有漏洞的WEB應用，然後在同一瀏覽器還打開了http://attacker.com(攻擊者的網站)，http://attacker.com可以嘗試通過該漏洞應用與應用的服務端建立一個WebSocket連接，然後通過瀏覽器發送一個帶有效的認證Session
ID的請求包。於是，這個由攻擊者網站建立的WebSocket連接會和應用本身有相同的許可權。

由於整個應用都是以websockets為基礎運行的，劫持了WebSocket就相當於劫持了用戶的session。所以這個漏洞在本質上和存儲型跨站腳本漏洞是一樣的。

如果你認為這就很糟了，那當你聽到某些情況下WebSocket跨站腳本，甚至可以在用戶系統上實現遠程代碼執行的時候，會不會更驚訝呢?事見IPython Notebook的案例。

測試之前，你首先要做的就是確認該應用是否存在WebSockets。幸運的是，做這個非常簡單，你只需要知道以下三點:

1.WebSocket的URL連接一般是以ws://或者wss://開頭的。

2.需要檢測建立連接的Origin頭，該網頁可能是通過Origin欄位建立的WebSocket鏈接。

3.瀏覽器和服務端之間發送的消息中，我們可以從中檢查出普通WebSocket連接的特徵。

下面這張圖會給你展示：如何通過IronWASP日誌得到Origin欄位的值和WebSocket的URL值。

一旦你得到這些信息，你可以使用一些特殊方法，對跨站WebSocket劫持漏洞進行檢測。我在這里例舉三個簡單的例子：

使用代理軟體(如Burpsuite):

這里必須提到的是，burpsuite可以捕獲和記錄WebSockets的消息。而ZAP和IronWASP是我所知道的，可以重放websocket請求的軟體。

在burpsuite里，我們不能重放websockets消息，但我們還是可以在有限條件下，檢測WebSocket握手包是否成功。為了進行測試，我們需要分析websocket的升級請求包：它們會通過http或者https發送，因此可以被重放。

以下截圖為burpsuite重放器(Repeat選項卡)的記錄，其顯示了websocket連接的有效請求和應答情況：

為了測試這個漏洞，我們需要發送另一個帶有重製後的Origin頭的請求包。如果我們回應包里有「101 Web Socket Protocol Handshake」的標志，這就表示WebSocket已經建立成功了。

如果連接沒有建立成功，那就意味著該應用不存在這個漏洞，因為它會拒絕外部的WebSocket連接。建立成功後，我們就可以開始下一步測試，看看該應用是否有WebSocket跨站劫持漏洞。這里需要說明一下：即使已經建立連接，也需要其如Origin的正常連接一般，確認得到服務端對WebSocket消息的應答之後，才能證明該應用存在漏洞。這是因為開發者可能會同時啟用Origin檢測與連接許可權認證。因此我們的實驗中也許會出下面這種情況：建立的連接可以一直保持，但擁有外部來源的Origins不會通過認證。

ZAP可以重放WebSocket消息，但據我了解，它並不能更改Origin頭。下面介紹的方法可以給你科普下，如何通過CSWSH(WebSocket跨站劫持)來獲得更多的東西。

使用WebSocket跨站劫持的在線測試工具

打開需要測試的WEB應用登入其中，然後在同一瀏覽器中開一個新選項卡，訪問http://ironwasp.org/cswsh.html(模擬的黑客網站)，輸入該WebSocket的URL地址，然後點擊網頁上的Connect按鈕。一旦建立連接，你就可以通過這個頁面向WebSocket的伺服器發送消息。我們需要通過重放有效session發送過的消息，然後查看伺服器的回應包。

如果服務端的回應與前面有效session發送的正常包相同，那就說明該應用可能存在WebSocket跨站劫持漏洞。

使用IronWASP

IronWASP可以做到更多，即使是最基礎的檢測也能提供自動化腳本檢查。

使用IronWASP的WebSocket客戶端

以上測試Origin的方法的使用的服務端是http://ironwasp.org，如果你想要更加靈活地設置Origin值，你可以使用IronWASP的客戶端功能。它允許你自定義Origin值來測試WebSocket連接。

在以下環境下可能會用到客戶端功能：

1.應用允許來自開放的Origin的WebSocket連接

2.應用允許來自localhost和內網IP的Origin欄位值

這種做法是為了方便開發者和應用的內部測試。通過使用IronWASP的客戶端，你可以嘗試內網IP或者localhost作為Origin是否能夠生效。如果可以的話，那沒准兒你可以耍一點小手段，在真實環境下利用這個漏洞。比如，如果某個應用允許http:/127.0.0.1:8080作為Origin欄位，那我們就可以這樣做：若受害者正好有個在本地8080埠運行的WEB應用，而且其存在跨站腳本漏洞。如果滿足這些條件，黑客可以先在該WEB應用上進行跨站攻擊，然後再向目標應用服務端建立WebSocket連接：

使用IronWASP的WebSocket API進行自動化檢測

如果你需要利用localhost或者內網IP進行測試Origin頭，使用客戶端腳本進行自動化檢測會讓你的行動更加輕松。IronWASP允許你使用Python或者Ruby進行實現自定義腳本編寫。

下面這個腳本可以單獨檢測Origin頭里填充的內網IP地址，測試服務端對此是否認可：
import clr
clr.AddReference("WebsocketClient.exe")
from WebsocketClient import *
def check_conn(origin):
print "Testing origin - " + origin
ws = SyncWebsockClient()
ws.Connect("ws://tatgetapp.com/ws", origin, "SessionID=KSDI2923EWE9DJSDS01212")
ws.Send("first message to send")
msg = ws.Read()
ws.Close()
if msg == "message that is part of valid session":
print "Connection successful!!"
return True
else:
return False
def check_nw():
for nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]:
for ip in Tools.NwToIp(nws):
if check_conn("http://" + ip):
break
check_nw()