本文目录一览：
- 1、SpringBoot 防止SQL注入、XSS攻击、CSRF/CROS恶意访问
- 2、谁能说一下脚本病毒的原理、攻击流程与防护、、更好详细点呀、网站也好、谢啦、、
- 3、写给ASP.NET程序员：网站中的安全问题
SpringBoot 防止SQL注入、XSS攻击、CSRF/CROS恶意访问
一、SQL 注入问题
SQL 注入即是指 web 应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在 web 应用程序中事先定义好的查询语句的结尾上添加额外的 SQL 语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。
简单来说，就是将大部分 SQL 语句当参数传入系统中，从而获取系统中的数据。下面简单举例说明
系统中有这样一条信息 SQL 语句执行，分页查询所有用户，每页查询 20 条，并且根据指定字段进行排序，也就是说排序字段也是参数传递过来的
SQL 注入问题分析：
这样很简单的一句话 SQL，就可以把系统搞炸掉，这种方式可以实现删库跑路
以上语句会把整个 test 数据库所有内容都删掉
尽量用预编译机制，少用字符串拼接的方式传参，它是 sql 注入问题的根源。
有些特殊字符，比如：%作为 like 语句中的参数时，要对其进行转义处理。
需要对所有的异常情况进行捕获，切记接口直接返回异常信息，因为有些异常信息中包含了 sql 信息，包括：库名，表名，字段名等。攻击者拿着这些信息，就能通过 sql 注入随心所欲地攻击你的数据库了。目前比较主流的做法是，有个专门的网关服务，它统一暴露对外接口。用户请求接口时先经过它，再由它将请求转发给业务服务。这样做的好处是：能统一封装返回数据的返回体，并且如果出现异常，能返回统一的异常信息，隐藏敏感信息。此外还能做限流和权限控制。
使用 sqlMap 等待代码检测工具，它能检测 sql 注入漏洞。
需要对数据库 sql 的执行情况进行监控，有异常情况，及时邮件或短信提醒。
对生产环境的数据库建立单独的账号，只分配 DML 相关权限，且不能访问系统表。切勿在程序中直接使用管理员账号。
建立代码 review 机制，能找出部分隐藏的问题，提升代码质量。
对于不能使用预编译传参时，要么开启 druid 的 filter 防火墙，要么自己写代码逻辑过滤掉所有可能的注入关键字。
XSS 攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的 *** 注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是 JavaScript，但实际上也可以包括 Java、 VBScript、ActiveX、 Flash 或者甚至是普通的 HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和 cookie 等各种内容。
通常情况下，被用来盗用 Cookie、破坏页面结构、重定向到其他网站等
对用户输入的表单信息进行检测过滤
CSRF - Cross-Site Request Forgery - 跨站请求伪造:
攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在未授权的情况下执行在权限保护之下的操作，CORS - Cross Origin Resourse-Sharing - 跨站资源共享，恶意访问内网敏感资源。
有效的解决办法是通过多种条件屏蔽掉非法的请求，例如 HTTP 头、参数等：
防止大规模的恶意请求，niginx 反向 *** 可以配置请求频率，对 ip 做限制。nginx 可以很方便地做访问控制，特别是一些偶发性的大量恶意请求，需要屏蔽处理。
屏蔽 ip 地址
屏蔽 user-agent
屏蔽 *** ip
有两种情形会需要屏蔽 *** ip：一是 *** ip 访问，二是负载均衡（real-ip 请求负载均衡服务器，再 *** 给后端 server）
创建 XssAndSqlHttpServletRequestWrapper 包装器，这是实现 XSS 过滤的关键，在其内重写了 getParameter，getParameterValues，getHeader 等 *** ，对 http 请求内的参数进行了过滤
谁能说一下脚本病毒的原理、攻击流程与防护、、更好详细点呀、网站也好、谢啦、、
通过对xss跨站脚本攻击漏洞的历史、攻击特点、攻击原理描述及案例代码实战举例详细解析XSS漏洞攻击技术，并提出防御XSS跨站漏洞的思路 *** 。及WEB开发者开发网站过程中防范编码中产生xss跨站脚本攻击漏洞需要注意的事项。
XSS漏洞概述：
XSS(Cross Site Script)跨站点脚本攻击是一种注射的问题，在这种恶意脚本注入否则良性和信任的网站类型。跨站点脚本（XSS）攻击，攻击者使用时，会出现一个 *** 应用程序发送恶意代码，一般是在浏览器端脚本的形式，向不同的最终用户。这些缺陷，使攻击成功是相当普遍，发生在任何地方从一个Web应用程序使用在输出它没有验证或编码了用户输入。攻击者可以使用XSS的恶意脚本发送到一个毫无戒心的用户。最终用户的浏览有没有办法知道该脚本不应该信任，将执行该脚本。因为它认为该脚本来从一个受信任的源，恶意脚本可以访问任何Cookie，会话令牌，或其他敏感信息的浏览器保留，并与该网站使用。 甚至可以重写这些脚本的HTML网页的内容。
XSS漏洞历史：
XSS(Cross-site scripting)漏洞最早可以追溯到1996年，那时电子商务才刚刚起步，估计那时候国内很少人会想象到今天出现的几个国内电子商务巨头 *** 、当当、亚马逊（卓越）。XSS的出现“得益”于JavaScript的出现，JavaScript的出现给网页的设计带来了无限惊喜，包括今天风行的AJAX(Asynschronous JavaScript and XML)。同时，这些元素又无限的扩充了今天的 *** 安全领域。
XSS 漏洞攻击特点：
（1）XSS跨站漏洞种类多样人：
XSS攻击语句可插入到、URL地址参数后面、输入框内、img标签及DIV标签等HTML函数的属人里、Flash的getURL()动作等地方都会触发XSS漏洞。
（2）XSS跨站漏洞代码多样人：
为了躲避转义HTML特殊字符函数及过滤函数的过滤，XSS跨站的代码使用“/”来代替安字符“””、使用Tab键代替空格、部分语句转找成16进制、添加特殊字符、改变大小写及使用空格等来绕过过滤函数。
如果在您的新闻系统发现安全漏洞，如果该漏洞是一个SQL 注入漏洞，那么该漏洞就会得到您的网站管理员密码、可以在主机系统上执行shell命令、对数据库添加、删除数据。如果在您的新闻或邮件系统中发现安全漏洞，如果该漏洞是一个XSS跨站漏洞，那么可以构造一些特殊代码，只要你访问的页面包含了构造的特殊代码，您的主机可能就会执行木马程序、执行^***Cookies代码、突然转到一个银行及其它金融类的网站、泄露您的网银及其它账号与密码等。
XSS攻击原理：
XSS 属于被动式的攻击。攻击者先构造一个跨站页面，利用script、IMG、IFRAME等各种方式使得用户浏览这个页面时，触发对被攻击站点的http 请求。此时，如果被攻击者如果已经在被攻击站点登录，就会持有该站点cookie。这样该站点会认为被攻击者发起了一个http 请求。而实际上这个请求是在被攻击者不知情的情况下发起的，由此攻击者在一定程度上达到了冒充被攻击者的目的。精心的构造这个攻击请求，可以达到冒充发文，夺取权限等等多个攻击目的。在常见的攻击实例中，这个请求是通过script 来发起的，因此被称为Cross Site Script。攻击Yahoo Mail 的Yamanner 蠕虫是一个著名的XSS 攻击实例。Yahoo Mail 系统有一个漏洞，当用户在web 上察看信件时，有可能执行到信件内的javascript 代码。病毒可以利用这个漏洞使被攻击用户运行病毒的script。同时Yahoo Mail 系统使用了Ajax技术，这样病毒的script 可以很容易的向Yahoo Mail 系统发起ajax 请求，从而得到用户的地址簿，并发送病毒给他人。
XSS 攻击主要分为两类：一类是来自内部的攻击，主要指的是利用WEB 程序自身的漏洞，提交特殊的字符串，从而使得跨站页面直接存在于被攻击站点上，这个字符串被称为跨站语句。这一类攻击所利用的漏洞非常类似于SQL Injection 漏洞，都是WEB程序没有对用户输入作充分的检查和过滤。上文的Yamanner 就是一例。
另一类则是来来自外部的攻击，主要指的自己构造XSS 跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个跨站网页放在自己的服务器上，然后通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。这一类攻击的威胁相对较低，至少ajax 要发起跨站调用是非常困难的。
写给ASP.NET程序员：网站中的安全问题
做项目也有一段时间了 在程序中也遇到很多安全方面的问题 也该总结一下了 这个项目是一个CMS系统 系统是用ASP NET做的 开发的时候发现微软做了很多安全措施 只是有些新手程序员不知道怎么开启 下面我通过几个方面简单介绍
SQL 注入
XSS
CSRF
文件上传
SQL 注入
引起原因
其实现在很多网站中都存在这种问题 就是程序中直接进行SQL语句拼接 可能有些读者不太明白 下面通过一个登录时对用户验证来说明
验证时的sql语句
select * from where user= +txtUsername Text+ and pwd= +txtPwd Text+
这是一段从数据库中查询用户 对用户名 密码验证
看上去好象没有什么问题 但是实际这里面浅藏着问题 用户名 admin 密码 admin
select * from where user= admin and pwd= admin
如果用户和密码正确就可通验证 如果我用户名 asdf or = 密码 随意输入
我们再来看语句
select * from where user= asdf or = and pwd=
执行后看到什么？是不是所有记录 如果程序只是简单判断返回的条数 这种 *** 就可以通验证
如果执行语句是SA用户 再通过xp_cmdshell添加系统管理员 那么这个服务器就被拿下了 解决 ***
a 这个问题主要是由于传入特殊字符引起的我们可以在对输入的用户名密码进入过滤特殊字符处理
b 使用存储过程通过传入参数的 *** 可解决此类问题（注意 在存储过程中不可使用拼接实现 不然和没用存储过和是一样的）
XSS（跨站脚本攻击）
引起原因
这个也有时被人们称作HTML注入 和sql注入原理相似 也是没有特殊字符进行处理 是用户可以提交HTML标签对网站进行重新的构造 其实在默认的情况下在asp net网页中是开启validateRequest属性的 所有HTML标签后会 NET都会验证
但这样直接把异常抛给用户 多少用户体验就不好
解决 ***
a 通过在 Page 指令或 配置节中设置 validateRequest=false 禁用请求验证 然后我们对用户提交的数据进行HtmlEncode 编码后的就不会出现这种问题了（ASP NET 中编码 *** Server HtmlEncode(string)）
b 第二种是过滤特殊字符 这种 *** 就不太提倡了 如果用户想输入小于号（）也会被过滤掉
CSRF（跨站点请求伪造）
引起原因 个人认为csrf在Ajax盛行的今天来说 倒是方便了 因为它可以在你不知道的情况用你的通过验证用户进行操作 所以也被称为浏览器劫持 如果你已通过某个网站的验证那么你将以你的角色对网站进行操作 比如你是管理员可以添加其它的用户到管理组 但是如果有人构造了添加管理员的链接被管理员点后也会执行相应操作
解决 ***
修改信息时添加验证码或添加Session令牌（ASP NET中已经提供一个自动防范的 *** 就是用页面属性ViewStateUserKey 在Page_Init *** 中设置其值 this ViewStateUserKey=Session SessionID）
文件上传
引起原因
如果你的网站使用的是在线编辑器 如FCKEditor eWeb等等 如果没有处理好文件上传 那么上线后网站会很快的被篡改
解决 ***
在用户登录时加入是否可上传文件的Session标志 其实Fckeditor已经写好了 直接把验证函数CheckAuthentication()中的注释段中
return ( Session[ IsAuthorized ] != null (bool)Session[ IsAuthorized ] == true );
注释去掉 在登录成功加入
Session[ IsAuthorized ] = true;
就可以了
lishixinzhi/Article/program/net/201311/15358
