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()