openresty+Lua构建高性能、高可靠、安全的登陆校验

openresty+lua构建高性能、高可靠、安全的登陆校验,主要目的的访问伪造 cookie 进行登录。在webserver层进行校验,直接告诉应用层校验结果,就可以避免上面的问题。openresty+Lua就是这样一种webserver上安全、稳定、高性能的实现,并且开发成本低的方案。


新建,access.lua 代码:


local secretkey='1234567890abcdefghi'
if ngx.var.cookie_uid == nil or ngx.var.cookie_username == nil or ngx.var.cookie_token ==nil then
ngx.req.set_header("Check-Login", "NULL")
return
end

local ctoken = ngx.md5('uid:' .. ngx.var.cookie_uid .. '&nickname:' ..ngx.var.cookie_username .. '&secretkey:' .. secretkey)
if ctoken == ngx.var.cookie_token then
ngx.req.set_header("Check-Login", "Yes")
else
ngx.req.set_header("Check-Login", "No")
end

return
2、



php生成 cookie页面:
<?php

$uid = 123;
$username = “jincon”
$secretkey = “1234567890abcdefghi”;
setcookie(“uid”,$uid,time()+3600);
setcookie(“username”,$username,time()+3600);
setcookie(“secretkey”,$secretkey,time()+3600);

?>

判断是否校验成功:
<?php
if($_SERVER[‘HTTP_CHECK_LOGIN’]){
	$uid = $_COOKIE[‘uid’];
	$username = $_COOKIE[‘username’];
}
?>


3、nginx 的修改:

location ~ [^/]\.php(/|$) {
        #添加 lua 加载。
        access_by_lua_file "/usr/local/openresty/nginx/lua/test.lua";
        fastcgi_pass unix:/dev/shm/php-cgi.sock;
        fastcgi_index index.php;
        include fastcgi.conf;
}


可能有的人说 HTTP 这样开头不都是可以伪造的嘛,是可以伪造,


但是了解 nginx 和 lua 执行流程就知道了,这里是不能伪造的,提供测试代码,你试试可能伪造:


<?php
$ch = curl_init();
$url = "http://192.168.1.58/test.php";
$header = array(
'Check-Login:No'
);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
$page_content = curl_exec($ch);
curl_close($ch);
echo $page_content;
?>

附nginx+lua 处理流程(自己看吧):

Nginx 处理每一个用户请求时,都是按照若干个不同阶段(phase)依次处理的,而不是根据配置文件上的顺序。
Nginx 处理请求的过程一共划分为 11 个阶段,按照执行顺序依次是
post-readserver-rewritefind-configrewritepost-rewrite preaccessaccesspost-accesstry-filescontentlog.

post-read:
读取请求内容阶段
Nginx
读取并解析完请求头之后就立即开始运行
例如模块 ngx_realip 就在 post-read 阶段注册了处理程序,它的功能是迫使 Nginx 认为当前请求的来源地址是指定的某一个请求头的值。

server-rewrite
Server请求地址重写阶段
ngx_rewrite 模块的set配置指令直接书写在 server 配置块中时,基本上都是运行在 server-rewrite 阶段

find-config
配置查找阶段
这个阶段并不支持 Nginx 模块注册处理程序,而是由 Nginx 核心来完成当前请求与 location 配置块之间的配对工作。

rewrite
Location请求地址重写阶段
ngx_rewrite 模块的指令用于 location 块中时,便是运行在这个 rewrite 阶段。
另外,ngx_set_misc(设置md5encode_base64) 模块的指令,还有 ngx_lua 模块的 set_by_lua 指令和 rewrite_by_lua 指令也在此阶段。

post-rewrite
请求地址重写提交阶段
Nginx 核心完成 rewrite 阶段所要求的内部跳转操作,如果 rewrite 阶段有此要求的话。

preaccess
访问权限检查准备阶段
标准模块 ngx_limit_req ngx_limit_zone 就运行在此阶段,前者可以控制请求的访问频度,而后者可以限制访问的并发度。

access
访问权限检查阶段
标准模块 ngx_access、第三方模块 ngx_auth_request 以及第三方模块 ngx_lua access_by_lua 指令就运行在这个阶段。
配置指令多是执行访问控制性质的任务,比如检查用户的访问权限,检查用户的来源 IP 地址是否合法

post-access
访问权限检查提交阶段
主要用于配合 access 阶段实现标准 ngx_http_core 模块提供的配置指令 satisfy 的功能。
satisfy all(与关系)
satisfy any(或关系)

try-files
配置项try_files处理阶段
专门用于实现标准配置指令 try_files 的功能
如果前 N-1 个参数所对应的文件系统对象都不存在,try-files 阶段就会立即发起内部跳转到最后一个参数(即第 N 个参数)所指定的 URI.

content
内容产生阶段
Nginx
content 阶段是所有请求处理阶段中最为重要的一个,因为运行在这个阶段的配置指令一般都肩负着生成内容并输出 HTTP 响应的使命。

log
日志模块处理阶段
记录日志


关键词: lua , openresty

上一篇: nginx+lua 实现简单的防机器程序访问
下一篇: 一个java解密算法改写为php解密算法的代码

目前还没有人评论,您发表点看法?
发表评论

评论内容 (必填):