我的架构经验系列文章 - 后端架构 - 安全层面

安全层面:

  • SQL注入

SQL注入是一个古老的安全问题,现在任何程序都不应该再出现这样的问题了,其原理非常简单,在过去大多数程序都是直肠子通数据库的,因此如果拼接SQL并且在参数上没有做好过滤或者没有使用参数形式来生成SQL语句的话可能会导致用户在页面上输入的恶意代码直接在数据库中执行。SQL注入的危害点在于整个网站有1000个数据点,如果其中有1个点有漏洞那么整站的数据其实都有危险了,很多开发会注重资金相关的模块但是忽略新闻相关的模块,如果都是使用一套数据库的话那么一个不重要模块的漏洞就会影响整站。也有一些开发比较会注意GET参数的验证但是会忽略POST参数的验证,这也是很容易出问题的,POST不会因为不在URL上显示就安全多少的,其内容还是用户在表单中输入提交的。在这里提SQL注入的问题是希望开发人员都有这个意识,整站的安全系数是以整站安全最薄弱的模块来衡量的,就像Windows的体验评分是以最低的那个数字来作为结果的而不是最高的那个数字作为结果的。可以500%提高开发效率的前端UI框架!

  • 客户端信任

做网站开发要有这个意识,任何客户端提交过来的数据都是不值得信任的,这包括GET参数、POST参数、COOKIE的内容。所有的这些都是可以伪造的,浏览器只是为了方便提供的一个HTTP的数据提交器和HTTP标签的解析器,黑客是不会使用浏览器的,HTTP头和主体中的内容可以随便改的。因此,对于任何客户端传过来的数据都需要进行严格的过滤和检查,脑子里始终有这么一个想法的话可以避免很多安全问题。另外,由于COOKIE是存在用户本地的也是客户端传过来的,其中的安全问题包括不能随便相信COOKIE中存的值,也不能随便把敏感的数据保存在客户端以免让用户自己的隐私信息得到泄露。一个简单的例子,如果我们通过COOKIE中的用户名来判断用户是否已经登陆的话,用明码的用户名肯定是不合理的,如果用户随便改一个管理员的用户名难道系统就认为是管理员登陆了?解决的办法是存一个加密后的用户名,但这样也是不安全的,因为一旦加密方法别破解的话还是会产生巨大的漏洞,因此可以在COOKIE中同时存用户名密码,也就是说网站其实是用你的用户名和密码帮你在一段时间内自动登陆,而不是真正记住你的登陆,由于我们还要确保用户的密码不会得到泄露(如果用户机器上有密码的话那么存明码的密码也是对用户的不负责),因此我们需要在COOKIE中存加密后的用户名和哈希后的密码,为了安全还可以把这两个数据再加密一次保存在COOKIE中。可以500%提高开发效率的前端UI框架!

时间: 2024-10-01 07:51:53

我的架构经验系列文章 - 后端架构 - 安全层面的相关文章

我的架构经验系列文章 - 后端架构 - 框架层面

框架层面: SOA 在这一篇中会逐个介绍一下自己对这些XXX的理解,其实每一个理念都不是莫名其妙产生的而是有产生背景的,这些时髦的名词不是用来炫耀的,而是真正要理解它们是干什么的,并且框架千万不能乱用理念也千万不能乱用,并不是把所有的这些都用上你的系统才是一个牛逼的系统,一定要适合才是最好的,并且要保持简单可靠的原则.所谓SOA,字面上来说是面向服务的架构.有的人不说SOA其实他已经SOA了,有的人大谈SOA但其实只是在用Web服务,SOA可大可小.你可以认为服务调用就是SOA了,也可以认为服务

我的架构经验系列文章 - 后端架构 - 架构层面

架构层面: 日志集中 所谓日志集中就是把程序的所有日志和异常信息的记录都汇总到一起,在只有一台服务器的时候我们记录本地文件问题也不是最大,但是在负载均衡环境下再记录本地日志的话就出现问题了.在想查看网站日志的时候到哪台机器去查都不知道,难道有100台机器就100台机器逐一远程连上去看?因此,把这些数据汇总在一起保存对于大型网站系统来说是很必要的,这样我们就可以直接进行查看.搜索,也很明确可以知道是哪台机器的业务出了问题.至于这种日志数据是写到RDBMS还是NOSQL甚至是搜索引擎这就看需要了,总

我的架构经验系列文章 - 后端架构 - 设计层面

设计层面: 分层架构 分层架构是项目设计中很重要的一点,从根本的目的上来说就是为了职责的分离.最经典的三层架构,到四层五层六层,甚至有人开玩笑说十八层的分层,根据项目的需要可以分不同的层.这里说的层其实是逻辑层,从物理层的角度来说也有三层.四层五层的分层架构.之所以三层架构这么流行是因为它的分层把大的关注点进行了分离,层数恰到好处,表现层.业务逻辑层和数据访问层,分别处理面向用户呈现的.面向逻辑处理的和面向数据库存取数据的三大关注点.UI前端框架最新力作!有奖试读! 在分层架构中除了分层之外还需

我的架构经验系列文章 - 后端架构 - 系统层面

系统层面: 高可用性 所谓高可用性也就是通过避免单独故障加上快速故障转移实现一旦某台物理服务器出现故障能实现故障快速恢复.一般来说,可以采用两种方式,如果可以做业务可以做负载均衡则通过负载均衡实现集群,然后针对每一台服务器进行监控,一旦发生故障则从集群中移除:如果业务只能有单点入口那么可以通过实现Standby机加上虚拟IP机制,实现Active机在出现故障之后虚拟IP转移到Standby的快速故障转移.一般可以使用KeepAlived或HeartBeat实现高可用(当然,硬件手段实现也可以,这

我的架构经验系列文章 - 后端架构 - 性能层面

性能层面: 性能分析 我觉得性能分析的话要注意几个要点: 不要去猜:对于自己写的代码你是否知道你的代码要执行多久,是不是还在用时间相减来测试代码执行时间?现在有很多自动化的工具可以在程序运行的时候,测试代码中每一句语句的执行时间,可以有效分析出代码的性能瓶颈.对于比较重要的业务逻辑建议采用类似的工具来进行性能分析,有的时候性能慢的代码不一定是自己写的还可能是框架内提供的,如果没有一个丰富的编码经验是不太可能知道这些点的,但是通过这样的分析工具你就能知道这个地方会慢,虽然框架的代码我们不能改,但是

我的架构经验系列文章 - 后端架构 - 语言层面

语言层面: 运行时元数据获取 所谓运行时元数据获取也就是在程序 运行的时候通过代码动态 获得类型.方法.属性的信息,然后可以动态获得属性的值,执行方法等等,在有的语言中称为反射.反射不一定是高效的,但是在写框架程序的时候反射是一种很有用的技术 ,并且反射的性能开销往往是可以通过诸如缓存等手段来最小化的.比如在ORM中,根据实体类的信息动态获得所有的属性,然后取得其值,生成要到数据库 中执行的SQL语句.理解反射熟练掌握反射的使用以及性能优化是编写框架类代码很重要的一点. 错误处理 任何后端语言都

我的架构经验系列文章 - 前端架构

框架层面:近几年前端发展很快,前端之所以叫前端因为前端是已经可以独立成为一种职业了,js也不再是十年前的玩具了,以前富客户端RIA的应用可能会用flash/flex或是silverlight,现在可以使用js来完成大部分的功能,因此js作为一门前端的支撑语言也不仅仅是进行的简单的编码,越来越多框架性的东西出现了.越来越多的开发模式转变为后端只是吐json的数据源,而前端做所有UI的事情. MVC MVC实现职责分离是很好的,大多数网站在后端都会引入MVC框架,对于一个前端负责所有呈现和前端业务逻

mysql 架构篇系列 2 复制架构一主一从搭建(异步复制)

一. 环境准备 1.1 主库环境(172.168.18.201) 环境 说明 查看脚本 操作系统版本 CentOS Linux release 7.4.1708 (Core) cat /etc/redhat-release 操作系统用户名和密码 root  js*2015 IP地址 172.168.18.201 ip addr 网关Gateway 172.168.18.1 cat /etc/sysconfig/network-scripts DNS 172.168.16.11 mysql 版本

NET架构设计、框架设计系列文章总结

NET架构设计.框架设计系列文章总结 从事.NET开发到现在已经有七个年头了.慢慢的可能会很少写.NET文章了.不知不觉竟然走了这么多年,热爱.NET热爱c#.突然想对这一路的经历进行一个总结. 是时候开始下一阶段的旅途,希望这些文章可以在发挥点价值作用. 架构设计: ElasticSearch大数据分布式弹性搜索引擎使用 (推荐) DDD实施经验分享-价值导向.从上往下进行(圈内第一个吃螃蟹DDD实施方案)(推荐) 软件工程-思考项目开发那些事(一)(推荐) SOA架构设计经验分享-架构.职责