江边闲话集

09/01/2017

Web安全-隐藏Web Server信息

Filed under: 一技之长 — 张太国 @ 12:09

这是一个非常容易忽略的点。

Web Server的信息包括:

  • Web Server的类型，常见的如Tomcat， Apache Httpd，Ngnix等。
  • 版本信息。即web server的版本信息。

为什么要隐藏这些信息呢？原因很简单，我们非常容易获取web server的软件信息。那么对于攻击者可以做什么呢？我们知道每种软件都是有漏洞的，尤其是对于这些著名的软件。如果出现安全性漏洞，一般都是公开的，而且有些漏洞有详细的复现步骤。

其他web server不在这里例举了。

所以，当攻击者知道web server信息，又加上这对每个漏洞的详细解释，攻击就简单多了。

那么如何隐藏web 容器信息呢？一般来说是可以通过配置解决的。

Apache Tomcat

可以在server.xml里的Connector的server属性解决。参考https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Apache HTTPd
security.conf里的ServerSignature Off

08/09/2017

Web安全- Command Injection

Filed under: 一技之长 — 张太国 @ 10:58

Command Injection，是指Web App调用系统命令去实现某些功能，同时因为不安全的web请求数据（例如Form，Cookie，HTTP header等）利用该功能造成一些安全影响。

实例

下面的例子便于理解。

本例子来源https://www.owasp.org/index.php/Command_Injection

下面的PHP代码会引起Command Injection:

<?php
print("Please specify the name of the file to delete");
print("<p>");
$file=$_GET['filename'];
system("rm $file");
?>

我们看看请求和返回。

请求

http://127.0.0.1/delete.php?filename=bob.txt;id

响应

Please specify the name of the file to delete

uid=33(www-data) gid=33(www-data) groups=33(www-data)

我们可以看到，如果执行web的function id足够大的话，是极有可能把不应该的数据删除了，例如filename为/，同时我们也可以看到该id所在的group。

解决方案

可以尽量使用API。例如上面要删除一个文件，可以使用php语言的api去删除文件，而不是调用OS的rm命令。

如果没有相关的API去调用，一定要调用这些command，务必做好命令的验证。就个人经验看，验证允许的command比验证不允许的command要简单一些。

07/09/2017

资源

Filed under: 管理之道 — 张太国 @ 23:15

的确，这里已经很久不更新了，最主要的原因是的确太忙了。除了在现有的团队上，我需要去带另外的一个团队，而且这个团队挑战更多，这也是我愿意接手的一个原因，跳出自己的舒适区。

以前的团队，一直负责一些产品，team稳定，按部就班，一切按计划去执行即可。而且同事们也很给力，很多事情他们都能做了，不用去操心，这种状态还是不错的。所以我有更多时间和客户去沟通。

但是，自从接手这个团队之后，我不得不面临几个问题，团队资源的紧缺，项目杂而且我还不熟悉，团队人员素质需要再上一个台阶，人员不稳定等。所以我现在逐步将自己的精力越来越多的放在这边。

但是有一点，对于已有的人员，我的想法是最大程度发挥他们的作用，整合资源，安抚他们。

04/25/2017

较真

Filed under: 闲情逸致 — 张太国 @ 23:16

一

很久没有对一件事情如此较真。现在的我，对于很多事情，基本上可以做到秉承着全力去做好的态度去做，还不至于让我费神费心。但是最近发生的一些事情，却让我较真起来。因为这些事情关乎女儿，同时发生在她的幼儿园的事情。看来我真是真爱女儿啊。

 

二

事情很简单，3月底，女儿所在的班有孩子突然呕吐，甚至发烧。接下来是第二个，第三个…孩子都发生这种情况，过了几天之后，女儿晚上也开始呕吐，但是呕吐之后也无大碍。第二天一早，将孩子送到医院就诊，抽血验血，基本上可以断定孩子之所以呕吐，是因为着凉了，即便如此，也在家里待了2天。看到这个结果，以及综合评估孩子的方方面买你，例如精神面，饮食等，，我们决定第送孩子去幼儿园。在休息这几天里，我们都是及时在班级群里更新孩子的状况。

去幼儿园一般需要晨检，保健医给了一个绿卡，但是我们向医院如实反映了孩子情况，医生建议我们继续观察一天。同时，我们将此事情继续更新到群里。但是，有的家长开始隐晦的表达他们不满。

同时，这几天，基本上也就只有6-8个孩子去学习，15~20%的出勤率，也是蛮恐怖的。

 

三

周末，女儿跟我说她的沙包扔的不好，我问女儿是什么时候的事情，女儿回到说不知道，然后转而将此事在群里问老师是什么时候的事情，而且建议老师可以直接联系家长。同时，也给出一个建议，定期开家长会。最后被老师给顶回来了，我知道老师误解了。

 

四

一般情况下，对于大部分事情我也是不会去理睬，我认为都不是什么事情。但是因为班级生病的事情，让我认识到一些问题。

  1. 为什么连续2-3个孩子都出现呕吐了而没有引起重视？是老师没有报告给学校还是报告了，学校不作为？
  2. 可以的话，应该将此事在群里通报一声，让家长及时了解情况。
  3. 最后连续几天个位数的出勤，学校没有及时更新状态。家长也没有。
  4. 老师告诉我没办法，即便有的孩子生病没好，因为家长上班忙，所以把孩子送到幼儿园来了。按学校规定，需要观察至少3天。甚至有的家长为了拿全勤奖，将病未痊愈的孩子送到幼儿园，老师和家长都没有按照规定来。
  5. 老师处理应急事情经验不够。

自从发现这些问题后，我逐渐开始对学校的管理方式和老师的个人素质上心了。当我碰见第二件事情后，本来一句很简单的话语，却被老师的回复搞的哭笑不得。关于此事，我发现

  1. 老师无法正视所发生的问题，对家长存在戒心。
  2. 家长在孩子上面永远是自私的，从这件事情我发现哪些家长值得交哪些不行。

四

我从来不是一个怕事的人，与其在后面发表一些不好的评论而什么都不干（敢），还不如将问题说出来，去解决。于是综合考虑，我还是想改变一些什么，至少目前的状态，老师和家长都是存在问题的。于是我第一个约老师谈。主旨在于家长，老师，孩子三方，是建立在沟通的基础上的。很明显，老师在这个方面的确做得很不够。

对于工作，不能仅仅是一份工作，如果是抱着这种心态，确实有点可怕。还记得另一篇文章，人最重要的能力是什么？

工作这么多年，也明白做事的方法和方式。

 

五

孩子的事儿都是大事儿，对于一些事情就得较真。与其在这里说，那点行动去做，更何况后果也没什么，我自己是个行动派，所以就去做了。二是我看到了我自己的另一面。三是也看到了家长们的真实心态，经过此事，把人性的隐藏的一点贪婪，虚伪，做作看的更清楚。

事后我在思考这件事情，现在来看一个良好的沟通平台没有建立起来，老师的个人素质，家长的个人素质，老师的收入等各个方面。

这也给我提了一个警醒，在孩子教育上需要花心思。

04/11/2017

生活和工作，真的分得开吗？

Filed under: 闲情逸致 — 张太国 @ 20:35

一

大学时，各个方面的信息都向我表达生活和工作要保持平衡，要分开。一直以来也是以此作为我做事儿的准则。直至前几年，这种思想在我心里面开始瓦解.在我的世界里，我逐步意识到工作和生活是无法分开的。

在我看来，的确有很多人或多或少都会将工作或者生活带到相互的领域去了，对此，我倒是可以理解的。

 

二

道理无需多言。生活幸福，在我看来首先是家庭幸福，但是家庭幸福也是以经济基础作为条件的（不要告诉我经济条件不重要，如果这样，权当我没讲）。如何实现经济基础，那就是收入。收入一般分工资性收入和非工资性收入。我想大部分人还是以工资性收入为主。工资收入来源于工作，如果工作不理想，哪来的丰厚性收入。

 

三

反过来，如何提高工资性收入，那就是工作要好。如何让工作好，至少我认为家庭幸福能给工作提供一个良好的基础。假设生活上出现问题，势必会把一些不好的事情或多或少带到工作上来。人不是圣人，再怎么理性也不会保证100%的事情全部理性。

 

四

所以，工作和生活是相辅相成的。工作好，才能促进生活。生活好，也能促进工作。两者关系都往一个积极好的方向去发展，这样两者皆可得。

现在还认为工作和生活真的分的开吗？

04/05/2017

工作方法是相通的

Filed under: 闲情逸致 — 张太国 @ 18:39

随着年龄的增长，开始觉得，无论是工作还是生活，方法都是相通的。

一个人，如果在工作上处理的很好，但是在生活上处理的却很糟糕，那肯定不是能力的问题，应该是没有用心去做。反之亦然。

见过不少人，观察他们的工作和生活，也逐步在验证我这个结论。

03/29/2017

人最重要的能力是什么？

Filed under: 闲情逸致 — 张太国 @ 14:27

一

最近因为在做performance review这件事情，让我再一次去评估整个团队。这引申出另外要给话题，到底人最重要的能力是什么呢？

带着这个问题思考了很久，这个答案终于我在心里越来越清晰。

是的，我的答案是主动，就是这个词。

刚开始我想了许多答案，例如学习能力，态度等，但是最终我觉得主动这个词挺能概括的。

 

二

人需要保持相当的主动。

举个例子，当自己一个住时，从起床到晚上睡觉发生的各种事情，是随心而欲呢，还是能够按照计划。说起床和睡觉，可能有些人因为周末睡个懒觉什么的，也许因为今天电视上正在播映一个好看的节目或是和朋友聊天太晚，导致晚睡。或是午饭时，觉得是自己一个人做饭没意思，所以随便吃一点。是的，各种各样的事情，当自己一个人时，能和平常做的一样好吗？我们能克制住自己吗？

现在几乎每个人都有微信，我们看看生活的周围大都是低头族。有人也意识到做低头族不好，但是如何才能做到呢？我们能克制住自己吗？

很多人做事情有时候是和心情有关的，当心情相反时，我们能主动的去做事情吗？

在工作时，工作不仅仅是工作，也是一件实现人生价值的事情，我们会主动认识到这一点吗？

在生活上，面对悲欢离合，我们能坦然面对，积极面对，难道这不是主动的表现形式吗？

 

三

主动，如果理解成主动学习，主动工作等，那就意味着把这个词看的太狭隘了，我们应该更高的理解它。

主动，首先是一种对人的心态的表现。同时，它也代表我们对生活以及工作的一种认知。

当我们在某件事情上获得成功时，我们需要让自己在喜悦的同时保持冷静。

当我们在某件事情上碰到问题时，我们需要让自己不要太悲观，分析问题，解决问题。

有人在工作上保持成功，同时我们也应该在生活上追求理想。

 

四

主动会让人追求一些更远大的目标，而不是一直停留在这里。也许有人在一个舒适区待了很久，但是不愿意突破。隔一段时间反省一下当前生活，舒适区？是否有冲动？当想清楚之后，想着去突破吗？

人的本性其实是懒散的，如何主动，那是一种境界。

 

五

现在的我也是有一些阅人的能力，基本上能简单看出谁主动，其实说白了就是考虑这个人在工作和生活上能达到我认为的高度。

当然，看其他人容易，但是看自己难。我认为最难的事就是如何清晰的看清自己。

03/14/2017

上海和北京地铁的出口标示

Filed under: 闲情逸致 — 张太国 @ 12:50

一

今天无意在地图上看见北京和上海这两个城市的地铁出口标示采用了不同的方案。

北京采用英文A,B,C,D…,而上海则采用数字,例如1,2,3,…

对此，我表现除了强烈的好奇心。这两种方案，到底哪一种好呢？如果我是地铁的设计人员，我应该如何设计？

针对此问题，我在微信上发了一条朋友圈，看看到底大家怎么说。

下面我试图站在设计者的角度去思考这个问题。

 

二

首先，出口的编号在我们的平常的生活种起到什么作用呢？考虑一下几种情景:

情景1： 我坐地铁去拜访一个朋友，这个朋友在地铁站外等我，打电话说让我在某某口见面。

情景2：我父母来北京或上海，我去接站，我跟父母电话说在某某口见面。

情景3：有位中学生坐地铁去北京站（或上海虹桥站),到站之后，问服务人员坐火车到那个口出。

情景3：有位从农村来的爷爷奶奶坐地铁去北京站（或上海虹桥站),到了站之后，问服务人员坐火车到那个口出。

以上的几种情景主要体现在沟通上，在这里沟通成本取决于文化程度，文化程度越高，对于字母识别率越高，沟通成本越低。基于此，看看这两种方案的沟通成本：

方案 高文化程度 低文化程度
数字标示 简单 简单
字母标示 简单 难

即便是字母，对于我们来说沟通费劲，例如B和D，很多时候教育程度高的人都要确认。数字好的多，暂时由4和10的区别，好多南方人10发布出来了。

 

三

再尝试考虑以下情景：

情景4: 有位从美国来的外国游客

情景5: 有位从俄罗斯来的外国游客。

上面的2种情景主要是考虑到外国游客，因为地铁是公共服务。显而易见，只有数字接口更易懂一些。毕竟数字全世界的人认识，而英文字母并不是全世界的人都认识。

 

四

再考虑下面情景：

情景6：如果有个站口超过26个出口，怎么办?

首先这种可能性非常容易出现，看看上海的徐家汇站，人民广场站，出站口还是蛮多。如果要是用字母表示，很显然不够用，数字相对来说好很多。但是北京现在也开始考虑字母+数字组合，例如A1，A2出口，这应该给交流带来更多灾难。

 

五

根据以上，我觉得数字方案会更好一些。但是这里有个问题，因为国内的地铁线都是1号线，2号线体现，如何在出口处将地铁线的数字标号和出口数字标示清晰分清楚？

显然，如果这个问题不解决，将会是灾难性的设计，导致人们根本不知道数字到底是地铁线或是出口。

看上海怎么解决的？

上海每条线都有非常清晰，可识别性非常高的颜色。

根据上图，数字标识的是地铁线或是出口还是容易识别，看右图的10号线，数字10 的矩形底色，而6号出口则非常大。

就我个人而言，这种挑战性还是比较大的，所以风险很大，如果做不好会适得其反。

 

六

无论是哪种方案都是要解决沟通问题，不同颜色代表不同地铁线是这样，数字标示还是字母标示也是这个目的，就看谁把这个问题解决的更好一些。

 

看看国内的城市分别用什么呢？

数字：上海，苏州，南京，长沙，重庆

字母：北京，杭州，西安，武汉，广州，深圳，香港，昆明，郑州，沈阳，大连，天津

看起来大部分城市都是用字母。

03/10/2017

一图

Filed under: 闲情逸致 — 张太国 @ 01:03

03/08/2017

软件开发规则

Filed under: 一技之长 — 张太国 @ 14:26
最后版本: rev 5
最后更新: 2017-04-21

设计

  1. 注重软件设计。
  2. High Available需要考虑。
  3. Geo Redundancy也需要考虑，如果设计web的话。
  4. 考虑软件的需求，有无可能复杂化，定制化，这决定了软件架构，
  5. 将需求详细化，但实现时简单化。
  6. 数据库主从结构，Replication，数据一直等。
  7. web的安全性方面是必须考虑的。
  8. 软件都是逐步迭代的，为了让后期迭代的成本更小，起点最好高一些。
  9. 事先定义软件的版本管理。
  10. 站在使用者的角度去思考。
  11. 解放思想，考虑问题站在高一点的位置。
  12. 防止过度设计。


Coding

  1. 一个文件代码不要太多，1K行左右，一个函数也不同太多，100行左右，如果太多的话，就应该考虑如何去分拆了。
  2. 代码一开始就要考虑模块化。
  3. 代码可重用性。
  4. 代码不能太耦合。
  5. 对于异常case务必写日志，不要认为捕获了就OK了。
  6. 良好的代码目录结构。
  7. 对于SQL等一些reserved keywords建议用大写，例如SELECT * FROM <tbl-name> WHERE field1=v AND field2 = v2
  8. 代码格式上须易于阅读，空格，空行等是必要的。Java有Java的代码规范，可以作为参考准则。
  9. 注释需要合理，不在于多，而在于精。对业务复杂的业务逻辑，加适当的注释会锦上添花。
  10. 代码格式可以利用一些专业化的工具进行检测，例如Sonar，JSLint等。
  11. 写代码是软件开发里非常简单的事情，但是做好不容易。基础非常重要。态度谦逊，借鉴优秀人员的代码，避免自己的不足。
  12. 一开始就要写好，不要以后面可以重构当借口。
  13. 对于web开发，安全性非常重要。可以写完后用安全扫描工具（例如AppScan等)进行扫描。掌握经验，在后面的coding种尽量去避免。
  14. 尽量将问题或需求想的全面，实现时根据实际情况可以取舍。
  15. 设计准备好了才可以写代码。
  16. 对于异常case多处理，不要认为发生的可能性不大。
  17. 尽量让代码的适应性强一些，考虑一些配置来适应未来的需求。
  18. 代码用Maven，Gradle等进行build
  19. 拼接SQL语句需要考虑的SQL安全性，SQL 的 保留关键字或字符，建议用PreparedStatement去完成。

Log

  1. 清晰的日志易于做troubleshooting
  2. 清晰的日志易于team之间的交流和学习。
  3. 日志注意拼写错误，英文合适。
  4. 日志需要将业务分步描述清楚。
  5. 建议developers多做Ops的工作，以便于了解到底什么样的日志才是优美的。
  6. 对于正常的业务也许打log，对于异常的case务必打log。常遇见的情况是正常的业务逻辑少，只有一些exception的case 才打。导致正常业务出问题没法进行troubleshooting。
  7. log的级别。什么样的信息适合什么样的log level，取决于业务。

SCM（SVN/GIT)

  1. 保证仓库里的代码是可以编译通过的。
  2. 代码尽量每天提交。
  3. 一次只提交一个功能或者bug fix代码。
  4. 提交代码时，写上comment描述当次修改。
  5. 如果是bug fix，在comment里注明bug id，如果是功能，注明requirement id。
  6. 安装合适的工具，例如Trac， Phabricator，以及Bitbucket等

Code Review

  1. 强烈建议team之间内部相互review。
  2. 条件允许的话，只有代码进行code review过了，才可以commit到仓库里。
  3. 开Code Review会议前，相关人员提前review一遍。在会议上只提问。
  4. Code Review时只提及修改的部分。
  5. Code Review可以用一些工具，例如Phabricator，ReviewBoard，以及Bitbucket等。

Test

  1. 写单元测试（Unit Test), 可以简单理解白盒测试。
  2. 写功能测试（Functional Test)，可以简单黑盒测试。
  3. 一般项目都会用daily build，将单元测试和功能测试加入daily build的task中。
  4. 代码覆盖率也很重要。
  5. 代码必须测试过才可以发出去（内部或者外部）
  6. Test Cases需要详尽才可以，认真写。
  7. Test Cases不是应付，不是交代，而是软件质量的一小步。
  8. 用测试框架去Test case,。例如，在Java里，很多人有个习惯是在class里增加一个main方法去驱动测试某个函数。

 

修改历史记录

  1. 2017-03-08, 第一版起稿。
  2. 2017-03-09, 增加测试部分，以及部分coding规则。
  3. 2017-3-13，增加设计章节。增加测试部分（>=6），log部分(>=6)，代码部分（>=14）等
  4. 2017-3-16，增加设计部分（>10）
  5. 2017-4-21, 增加coding 的18，19，修改Log的6
Older Posts »

Powered by WordPress