Anarckk
转载:https://www.cnblogs.com/loveyoulx/p/9526068.html
SQL注入本质上,是程序将用户输入的参数当成命令的一部分进行解析,从而使用户可以自由搜索我们的数据库中的记录。
解决方法,是将用户输入的内容进行解析和转义,将用户输入内容中的恶意代码转为普通字符串,从而保护数据库不被攻击。
SQL注入攻击,简称SQL攻击或注入攻击,是发生于应用程序之数据库层的安全漏洞。简而言之,是在输入的字符串之中注入SQL指令,在设计不良的程序当中忽略了检查,那么这些注入进去的指令就会被数据库服务器误认为是正常的SQL指令而运行,因此遭到破坏或是入侵。
最常见的就是我们在应用程序中使用字符串联结方式组合 SQL 指令,有心之人就会写一些特殊的符号,恶意篡改原本的 SQL 语法的作用,达到注入攻击的目的。
举个栗子:
比如验证用户登录需要 username 和 password,编写的 SQL 语句如下:
1 | String querySql = "select * from user where (name = '"+ username +"') and (pw = '"+ password +"');"; |
username 和 password 字段被恶意填入
1 | username = "1' OR '1'='1"; |
与
1 | password = "1' OR '1'='1"; |
将导致原本的 SQL 字符串被填为:
1 | select * from user where (name = '1' or '1'='1') and (pw = '1' or '1'='1'); |
实际上运行的 SQL 语句将变成:
1 | select * from user; |
也就是不再需要 username 和 password 账密即达到登录的目的,结果不言而喻。
在windows平台下,使用系统的记事本以UTF-8编码格式存储了一个文本文件,但是由于Microsoft开发记事本的团队使用了一个非常怪异的行为来保存UTF-8编码的文件,它们自作聪明地在每个文件开头添加了0xefbbbf(十六进制)的字符,所以我们就会遇到很多不可思议的问题,比如,网页第一行可能会显示一个“?”,明明正确的程序一编译就报出语法错误,等等。
下面为一段测试程序,由记事本编辑的文本文件导致文件开头前三个字符乱码。
自从docker容器出现以来,容器的网络通信就一直是大家关注的焦点,也是生产环境的迫切需求。而容器的网络通信又可以分为两大方面:单主机容器上的相互通信和跨主机的容器相互通信。而本文将分别针对这两方面,对容器的通信原理进行简单的分析,帮助大家更好地使用docker。
基于对net namespace的控制,docker可以为在容器创建隔离的网络环境,在隔离的网络环境下,容器具有完全独立的网络栈,与宿主机隔离,也可以使容器共享主机或者其他容器的网络命名空间,基本可以满足开发者在各种场景下的需要。按docker官方的说法,docker容器的网络有五种模式:
今天新买了一台云服务器,看了下 top,显示1882892Kib,突然发现,自己不太懂Kib是什么单位,所以查找了一下资料
KiB、MiB、GiB、TiB等,由国际电工委员会(IEC)于2000年制定,为什么要指定这个规范呢?因为国际单位制中TB、GB、MB、KB是“1000进制”的数,为此国际电工协会(IEC)拟定了”KiB”、“MiB”、“GiB”的二进制单位,专用来标示“1024进位”的数据大小
各类“服务器推”技术原理与实例(Polling/COMET/SSE/WebSocket)
主要是4中方法: 轮询、COMET、SSE (Server-Sent Events)、WebSocket
轮询简单易实现,问题是连接数量多会挤爆服务器
COMET 包含两种: 基于HTTP的长轮询(long-polling)、基于iframe的长连接流(stream)模式
SSE (Server-Sent Events) 是HTML5标准中的一部分。其实现原理类似于我们在上一节中提到的基于iframe的长连接模式。
HTTP响应内容有一种特殊的content-type —— text/event-stream,该响应头标识了响应内容为事件流,客户端不会关闭连接,而是等待服务端不断得发送响应结果。
SSE规范比较简单,主要分为两个部分:浏览器中的EventSource对象,以及服务器端与浏览器端之间的通讯协议。
WebSocket与http协议一样都是基于TCP的。WebSocket其实不仅仅限于“服务器推”了,它是一个全双工的协议,适用于需要进行复杂双向数据通讯的场景。因此也有着更复杂的规范。