首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
华为云
V2EX  ›  程序员

如果重构一个 web 项目,不考虑性能,只考虑安全,开发速度要快,哪种语言的哪种框架比较合适?

  •  
  •   shijingshijing · 282 天前 · 9114 次点击
    这是一个创建于 282 天前的主题,其中的信息可能已经有所发展或是发生改变。

    事情是这样的,美帝客户有一个零部件管理系统,用的是上古的 ASP 开发的(是那种 asp 标签和 html 混合编写的,不是现在的 ASP.Net ),因为一直是内网用,跑在 windows 2003 server 上,也没出什么毛病,就没有重新开发。

    现在的问题是,整个公司的业务流程发生了变化,为了提高效率,他们想在国内、泰国、德国建立多个小型仓库,每个仓库要能够访问,而且还要开放给供应商使用,因此决定放到 web 上。

    我看了一下业务逻辑,基本上都是 CRUD,没什么复杂的东西,重构应该不复杂。但是数据包含了供应商的报价信息等敏感内容,不能够对外公布,因此特别强调安全性。

    目前还没有定实施方案,还在让我做咨询,我需要给他们提供多套方案进行比较,proposal 里面需要一些比较有力的证据或者数据来支持,本人 web 这一块写写业务没问题,谈不上精通,目前写过 PHP ( CodeIgniter,ThinkPHP ),Python(Django),.Net MVC。

    另:他们有一些倾向:
    1,尽量使用 LAMP 这种开源的方案,微软的方案应该是不会考虑了,不然也不会一直用这个 win 2003 server。
    2,他们也不倾向于用 Java,倾向于用 PHP 或者 Python (可能也有我的影响的因素吧),后续有一些自己的设备比如扫码枪、仓库摄像头产生的数据会接入到这个系统。
    3,他们不会一次性全部转移到这个新的平台上来,可能会逐步的拿某个国家的一两个小仓库做试点,如果效果不错,再逐步部署迁移。
    4,他们反复强调了安全这一块,报价和供应商的信息是绝对不可以泄漏出去的,关系他们的饭碗。

    希望各位 web 大佬能畅所欲言。如果后续有办法接过来,可能也会请大佬们来一起分包。

    第 1 条附言  ·  281 天前
    谢谢各位大佬分析,看完获益匪浅,同时也有点瑟瑟发抖。。。

    这样吧,再具体明确一下:

    1,环境就是在 Debian 的 vps 上跑了,要么 LAMP 全家桶,要么 Python 的各种轮子组合。
    2,框架要开箱即用的,不需要折腾太多。说白了吧,主要是不需要我太多维护,框架拿来就用,稍微配置一下最好是不要配置。最好是无脑配好了直接上来撸 CRUD 业务代码。
    Django 自带 Admin 后台这种最好,PHP 的框架太多,选择困难,高档货 Laravel 这种本身比较重,还需要花点时间理解框架本身的,感觉不太合适。(哎,说到这里感觉不如找个 CMS 搞二次开发了。。。)
    3,一般需要注意的比如跨站防注入肯定要做到位,https 肯定要上,其他的比如防 D 这种感觉还是交给卖鸡的老板吧,大不了花点钱找个好点的鸡场,有问题交 ticket。一般也不会盯着这种小业务量的站点猛 D 吧。。高安全要多花钱这是肯定的,一分钱一分货都懂,但是毕竟比不上大厂,我自己也不是搞 security 的,老板们预算也有限,尽可能吧。
    4,维护这一块,我想最好是弄个脚本,反正定期无脑更新,有更新就上,不管是操作系统还是框架还是用到的第三方的轮子什么的,勤备份,升挂了大不了回滚。

    感觉选来选去可能最后还是 Django 了。。。
    116 回复  |  直到 2018-01-16 22:43:27 +08:00
    1  2  
        101
    tylerdurden   281 天前
    安全工程师告诉你,和语言无关。。。
        102
    tylerdurden   281 天前   ♥ 6
    和语言无关:
    1、mod_security 运维成本很高,建议使用 lua+openresty
    2、 注意权限控制,所有涉及到 id 的地方使用 uuid 来标识,规避遍历风险
    3、 输入输入输出的字符控制,使用常见 CSP 来防护前端风险。
    4、CSRF 漏洞数量一定要为 0,CSRF 漏洞数量一定要为 0 ;
    5、 文件上传点一定要注意做检查,文件类型,文件后缀,能放沙盒放沙盒;
    6、对数据隐私级别做定级,私密级别一定要用 AES 等做加密,私钥不要写死在程序里面。
    7、控制服务器的数据外连,SSRF 啊什么的专门打这种,所有对外连接白名单;
    8、https,https,ECDH ECDH,https 的加密要有所选择,具体可以搜
    9、 有空了解下 owasp top 10
    10、DDOS 不要怕,考虑 CNAME 解析,可以用国外免费抗 DDOS 服务。
        103
    tylerdurden   281 天前
    @lolizeppelin 说到点子上了,不谈钱谈安全都是 sb
        104
    aksoft   281 天前
    php 死的不快
        105
    kingcc   281 天前
    熟悉什么用什么,你比较了解 php 就用 php,语言难道还有安全不安全一说
        106
    wellsc   281 天前
    @SlipStupig #12 大兄弟,安全问题是怎么跟语言动静态属性扯上关系的?去事实出处
        107
    huamiao   281 天前   ♥ 1
    同意 @aqwei 你用任何框架都不能规避风险,还不如从网络结构上入手,风险可控性更高。
        108
    tailf   281 天前
    @Totato5749 是啊,Rails 的开发速度已经落伍,还有一堆别的问题。
        109
    inisun   281 天前
    如你自己所说的,不考虑 Java 因为不熟悉,这不就已经是答案了吗?选择了自己不熟悉的技术栈,即使语言设计得再好,框架设计得再合理,风险怕是更高。另外这方面的事情,扔给架构师先设计不更好?
        110
    shijingshijing   281 天前
    谢谢各位大佬分析,看完获益匪浅,同时也有点瑟瑟发抖。。。

    这样吧,再具体明确一下:

    1,环境就是在 Debian 的 vps 上跑了,要么 LAMP 全家桶,要么 Python 的各种轮子组合。
    2,框架要开箱即用的,不需要折腾太多。说白了吧,主要是不需要我太多维护,框架拿来就用,稍微配置一下最好是不要配置。最好是无脑配好了直接上来撸 CRUD 业务代码。
    Django 自带 Admin 后台这种最好,PHP 的框架太多,选择困难,高档货 Laravel 这种本身比较重,还需要花点时间理解框架本身的,感觉不太合适。(哎,说到这里感觉不如找个 CMS 搞二次开发了。。。)
    3,一般需要注意的比如跨站防注入肯定要做到位,https 肯定要上,其他的比如防 D 这种感觉还是交给卖鸡的老板吧,大不了花点钱找个好点的鸡场,有问题交 ticket。一般也不会盯着这种小业务量的站点猛 D 吧。。高安全要多花钱这是肯定的,一分钱一分货都懂,但是毕竟比不上大厂,我自己也不是搞 security 的,老板们预算也有限,尽可能吧。
    4,维护这一块,我想最好是弄个脚本,反正定期无脑更新,有更新就上,不管是操作系统还是框架还是用到的第三方的轮子什么的,勤备份,升挂了大不了回滚。

    感觉选来选去可能最后还是 Django 了。。。
        111
    jhdxr   281 天前
    @tbxxx 反序列化这个 PHP 开发组的态度已经很清楚了,开发者应该确保被反序列化的数据的来源是自己可信的。我觉得这个态度没什么问题,java 同理。至于文件包含,真的很多年没听说过相关的洞了,不知道大佬有没有什么新的洞可以来分享下?

    另外我很好奇一点就是 Python 社群的人是哪来这么的自信,PHP 和 java 能天天 0day 呼连上,Python 一朵白莲花屹立不倒的。
        112
    tylerdurden   281 天前   ♥ 1
    @shijingshijing 语言真的不是最重要的, 安全思维才是。
    啰嗦一点,鄙公司用的 php,用的 yii 框架,目前出现的安全问题大多出现在:自行进行 sql 拼接、上传不做检查(有沙盒以及权限控制所有危险很低)、ssrf 打后台。
    python 本生在对参数进行数据库操作的时候,也需要考虑防止 sql 注入、上传防护等。

    总之,私以为框架是不能帮你解决所有安全问题的,但是安全意识会。在所有用户输入点有针对性的 过滤,转义、检查、白名单等,可以解决很多问题。

    但是如果框架本生有问题,例如 struts2 那就嗝屁了。从 CVE 上看,django 的漏洞问题还算保持的不错,拱参考: https://www.cvedetails.com/product/18211/Djangoproject-Django.html?vendor_id=10199

    祝题主编最安全最高效的代码:)
        113
    prolic   281 天前
    ASP,那就是项目带 view 层,还是 jinja2 撸起来能快点吧
        114
    httplife   281 天前
    openresty + ruby on rails.
        115
    leisurelylicht   277 天前
    怎么说呢,你们还是没理解我说的和语言无关,和人有关。

    @husky 你的这套推导式前面都没什么问题,只是后面还缺了一步,就是更安全的开发规范有没有被使用。

    事实上实际工作过程中因为各种各样的因素,更安全的开发规范可能都没人看。比如 PHP 有很多函数都有为了安全而开发的新函数,但是不是所有人都知道这些安全变更呢?不一定的,看人。

    其次你的这个掩耳盗铃的比喻不是很恰当,真的要说的话应该是这样。

    我们现在要去一个目的地,有两条路都可以到达,分别叫 PHP 和 Python。然后叫 PHP 的这条路上有 100 个强盗等着抢劫过路的人,而叫 Python 的这条路上有 10 个强盗等着抢劫过路的人。

    你觉的哪条路更安全?

    当然是取决于你能雇佣到的保镖多少了,也就是你能投资的资源是多少。但是 Python 所需要你投资的资源肯定是少于 PHP。

    这样说你能明白吗?

    @jhdxr 关于你所得 0day 的问题,确实 Python 如果出 0day,传播速度肯定是要慢于 PHP 的。

    但是你的问题在于你只知道 0day,却不知道一次完整的渗透过程是不可能只靠一个 0day 来完成的,你明白吗?

    黑客真的要黑你必然是一堆 Nday 加上关键点的几个 0day。现在 0day 你有了,那些 Nday,你要去哪里找呢?

    那些 Nday 的 EXP 你又要去哪里找呢?全部自己写吗?说不定这个 0day 被补好了你都没写完。

    在 CNVD 上用 Python 做关键字搜索只能搜到 622 条,而用 PHP 搜索能搜到 15823 条。你确定这种数量级的碾压不会对现实使用过程的安全体验造成影响?

    至于你说的广撒网,你真的以为黑客都那么闲的吗?除了 apt,没有什么黑客会专门盯着一家不放的,大家都是用各自的扫描器在公网上广撒网,能避过这一击,就已经可以减少很多攻击了。

    最后说下,而且搞工程不是搞学术,搞工程是各方权衡的后果,有多少钱,多少时间,多少人,什么人,多少资源,什么资源都是影响安全的因素。不是想你们想象的这样,语言都不安全,所以一个语言不可能比另一个更安全。

    只要是在限定条件的情况下,可以。
        116
    jhdxr   274 天前
    @leisurelylicht 不需要用我是这种完全不懂的弱智的语气来和我说话。一个完整的渗透过程,往往**只需要一个具有杀伤力的 0day**,例子我在之前的回复中应该已经给出来了,请参考 struts2 那么多远程代码执行的洞,以及乌云还活着的时候被刷屏的截图。

    你用 cnvd 上搜到的数据来做例子,那么你能告诉我,以 PHP 为例子,你搜到的结果中,有多少是 PHP 语言自身的漏洞,又有多少是使用 PHP 语言开发的应用的漏洞?在语言自身,好吧让我们再加上常见的框架的漏洞中,中高危的又有多少?

    你不想谈 APT,我觉得可以理解,跳过。广撒网用扫描器我也认,那在自研,而非随便找个第三方的成品做个二次开发的情况下,你真的觉得用 PHP 的更容易被命中?就因为你上面说的那个并没有什么意义的『数量级的碾压』?


    另外我不妨稍微给你的例子补充下,如果所有强盗都是 lv1,而你雇佣到的保镖是 lv10,那有多少强盗就没什么区别了。而雇佣哪个语言的 lv10 的保镖的成本更低呢?(具体问题具体分析,LZ 这个例子很明显他对于 Django 更熟;但通用的情况也是如此么?)

    所以我的观点还是,人比语言重要。语言真的,差不了多少。
    1  2  
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3248 人在线   最高记录 3762   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.1 · 25ms · UTC 07:41 · PVG 15:41 · LAX 00:41 · JFK 03:41
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1