Front and rear separation of security issues

网站安全策略

最新推荐文章于 2025-01-11 09:54:11 发布

原创最新推荐文章于 2025-01-11 09:54:11 发布 · 656 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#server #web #secriuty

本文提出了一套网站安全策略，包括使用POST请求、同源策略、RSA加密传输敏感信息、登录验证时使用临时token以及防范cookie被伪造的方法。

登录验证以及安全问题：
1、请求接口全部用post方式，在后端判断请求方式是否为post
2、前后端代码放在同一服务器，在后端判断请求的来源是否与服务器同源：

$source_url = parse_url($_SERVER['HTTP_REFERER']);

$server_url = isset($_SERVER['HTTP_X_FORWARDED_HOST']) ? $_SERVER['HTTP_X_FORWARDED_HOST'] : (isset($_SERVER['HTTP_HOST']) ? $_SERVER['HTTP_HOST'] : '');

if($source_url['host']!=$server_url){
    //不同源，禁止访问
}

3、登录密码等敏感信息要加密后传输，如用RSA（支付宝里可下载公私钥生成工具），客户端公钥加密，传到服务器后再用私钥解密：

//js公钥加密
function encrypt(data)
{
    //需要引入插件jsencrypt.js 下载地址http://download.youkuaiyun.com/detail/codercwm/9770398

    var RSA_PUBLIC_KEY = '';//私钥写在这里

    var obj = new JSEncrypt();

    obj.setPublicKey(RSA_PUBLIC_KEY);

    var data = obj.encrypt(data);

    return data;
}

//php解密函数
function decrypt($data) {
    $data = base64_decode($data);

    //读取私钥
    $key_private = file_get_contents('./rsa_private_key.pem', 'r');

    //进行解密
    if(!openssl_private_decrypt($data, $data, openssl_pkey_get_private($key_private))) {
        return false;
    }

    return $data;
}

4、登录验证问题
（1）前后端代码放在同一个服务器，依旧可以使用session保存登录信息；
（2）在登录过程中，如果密码是明文提交，传输过程中可能会被拦截，即使加密后传输，也可用拦截到的已加密密码直接请求服务器进行登录，而且因为加密的代码是在客户端js中的，黑客可以修改客户端js，用拦截到的已加密的密码绕开此加密代码请求服务器进行登录，这是非常危险的，所以我想出了如下方案：

请求登录页面时，服务器生成一个临时token存储在服务器（session）并返回给客户端，用户提交登录时把密码和临时token拼接后通过RSA加密传回到服务器（拼接后再加密的原因是为了防止别人拦截到单单是密码加密的字符串，因为如果拿到了单单是密码加密的字符串，即如上面所说的，无论如何也可以进行假冒登录的），传到服务器解密后把密码和token取出，判断token是否正确，若正确即进行密码判断等一系列登录操作，登录成功后销毁这个临时token。 
这样即使在用户提交数据的过程中数据被拦截，拦截到的数据也是密码和临时token拼接后加密的数据，即使黑客用此数据直接对服务器进行请求，因为用户登录成功后临时token已被销毁，所以黑客并不能登录成功。

5、关于拦截和伪造cookie进行登录的预防：
（1）用户登录后，由于是用cookie记录sessid，如过请求过程中cookie被拦截，黑客就可以利用此cookie中的sessid在另一台电脑上进行登录，直至用户退出登录服务器session被销毁，这样是非常危险的，所以我想出了如下方案：

登录后生成一个临时token储存到服务器并传回到客户端，客户端下次请求时把此token传到服务器，判断与服务器中储存的token是否一样，如不一样即为未登录，如一样即销毁此token并生成新的token返回到客户端让客户端在下一次请求的时候再传回进行判断，如此重复。 
这种方法也有一个漏洞，如果用户在一次请求后，还未进行下一次请求就已被黑客拦截到登录信息并进行假冒登录，他一样可以登录成功并使用户强制下线，但这种方法已大大减少被假冒登录的机会

6、结合4、5两种方案，我的做法如下：

用户请求登录页面的时候，服务器生成一个token保存在服务器session中和客户端cookie中，登录时客户端带上此token一起提交到服务器，验证此token是否有效，若有效即登录成功并更新此token，重新赋值到session和cookie中； 
登录后的用户在每一次请求时都判断cookie中的token和session中的token是否一样，若一样即登录有效，并且要更新token，下次请求再进行判断，若不一样即登录无效。