前端开发如何防止逆向以及对策

前端开发分析代码的途径最简单不过了,第一个途径是查看网页源代码,第二个途径是打开开发者工具审查元素。

# 防止查看源代码

现在网站的基本对策是禁用用户右键选项菜单来避免查看源代码。首先,源代码肯定是能查看到的。采取的措施也只不过是掩耳盗铃而已。解决对策也有很多,我随便说几个。

第一,针对 Chrome 浏览器,我们可以直接在地址栏里输入 view-source:https://www.google.com/ 这种方式来查看源代码。第二,我们可以使用其他工具,例如curl, wget来直接下载源代码。

这种是很初级的防范对策。

# 防止审查元素

现代化的前端开发,都是基于 JS 来渲染页面元素的,有时候我们查看源代码也只是看到了 JS 文件的引用。没有太大意义,所以需要浏览器渲染之后查看真正的 DOM 元素才有意义。这时候如何禁止审查元素就是另外一种对策了。 现在用来检测打开开发者工具主要是通过判断console.log的执行,因为不打开开发者工具的话console.log是不会执行的。所以有些网站就可以利用这个来阻止用户打开开发者工具审查元素和 Debug 代码。 下面给出一个例子来:

<script>
let el = new Image();
Object.defineProperty(el,'id',{get: function(){window.location.href="http://www.bimibimi.tv"}});
console.log(el);
</script>
1
2
3
4
5

这是一个非常巧妙的例子,当执行console.log输出 Image 元素的时候,比如会访问 id 属性,从而触发后面的重定向 URL 代码。所以表现就是用户试图打开开发者面板就会被自动定位到首页。

要破解这个的话,只能在页面执行之前注入代码修改 Image 函数的使用:

window.Image = function () {};
Object.defineProperty(window, 'Image', { writable: false });
1
2

通过注入上面的代码,来规避自动跳转到首页。如何注入呢? 就需要利用 Chrome 的扩展功能,详细代码请参照bimibimi-hack

# 总结

前端代码逆向和反逆向,永远没有银弹。只能说是提高逆向的门槛,但想完全防止是不可能的。如果自己编译一个浏览器,修改浏览器的默认行为的话,就没有不能调试的网站。

# 引用

Find out whether Chrome console is open

Source code of bimibimi.tv

前端部署之CDN的那些事情

现在的前端开发主流是 PWA,简而言之就是像 App 一样使用。基于 PWA 技术可以离线访问,并且可以添加程序到菜单里。离线技术使用的是比较成熟的 Service Workers。但是配合 CDN 就有很多不得不注意的事情。

# CDN 部署静态资源

现代化前端开发主要是把 CSS,JS,图片等静态资源放在 CDN 上有效提高载入速度。把静态 HTML 文件放在服务器上,有利于更新网站最新状态,例如进入维护状态,直接把静态 HTML 文件替换为维护页面即可。

# 同源策略问题

正常情况下,资源文件和主网站不在同一个域名下,例如主网站是icehoney.me,资源网站是static.icehoney.me。当然了,资源文件使用 GET 方法浏览器自动载入,没有任何问题。但是注册 Service Worker 的 JS 文件是不能放在 CDN 上的,因为这是官方的规定。个人理解是出于安全因素的考虑。所以我们在主服务器上不仅要放静态的 HTML 文件,还要放一个 serive-worker.js 文件。

# SVG symbol 的使用问题

现在前端的开发针对很多小图标,都是采用 SVG 的方式来引用。其中 SVG symbol 特别好用,可以在页面里嵌入一个 inline 的 SVG,然后在其他对方使用<use>标签来引用。但是对于放在 CDN 上的 SVG 文件,不能直接使用下面的形式:

<use xlink:href="https://static.icehoney.me/icon.svg#china" />
1

如果引用 CDN 的 SVG 浏览器会报错,解决方案是使用svg-inline-loader,手动在文档里面注入 SVG 文件。document.body.insertAdjacentHTML 方法可以注入 inline 的 SVG。

# Workbox 配置

首先,PWA 项目的路由都是由前端来处理,所以我们需要使用navigateFallback保证不管导航到哪个路由都能映射到缓存的 HTML 文件。然后是使用runtimeCaching配置缓存服务器请求。

# 总结

由于 Service Workers 的导入使得 CDN 部署变得有些麻烦,不过这些问题好在都能找到解决方案。还有一点是 Chrome 的 Network 面板里的 offline 模式不能测试 Service Workers 的离线。需要自己手动拔网线才能测试。

# 引用

Is it possible to serve service workers from CDN/remote origin?

Workbox webpack Plugins

前端开发的技术栈

我发现自己博客没次开头都是在说近况和废话。这次也不例外。哈哈哈,工作也算顺畅,顺便总结下最近的前端开发的技术栈来回顾下这半年学到的知识。

# HTML 开发

对于大型项目,直接书写 HTML 代码是一个非常繁琐和头疼的事情,因为 HTML 需要闭合,每次找匹配的 HTML 标签都要非常花功夫。所以现在的开发都是使用预处理器来书写代码,例如主流的Pug,通过缩进来控制元素的嵌套,还支持多种语法。非常适合大型项目的开发,再也不用担心修改代码的时候出现 HTML 元素标签没有闭合的情况发生了。而且还规避了一些语法错误,例如在p标签里嵌入block元素是非法的。如果强行嵌入的话,你会发现生成的 HTML 代码是错误的。

# CSS 开发

CSS 开发更多的需要是良好的模块化功能和合理的作用域。这时候也需要通过预处理器来进行操作,推荐使用SCSS。这里很多人对sassscss之间的区别有疑问。简单的来说,SCSS的格式更接近 CSS,所以比较容易上手。但是SASS是通过缩进来书写的,对新手不太友好。所以建议大家使用SCSS来书写模块化代码。

# JavaScript 开发

现在主流的浏览器支持的 JavaScript 版本是 es5。但是众所周知,JavaScript(es5)有很多陷阱和缺点,例如this指针问题和异步处理等等。基于原型连的继承对于面向对象开发者来说也很不友好。所以推荐使用es6来书写代码。可以使用基于class的继承,和解决this指针问题。而且还能使用import进行模块化开发。虽然只是语法糖,但也提升了开发效率。

# 自动化构建工具

我们使用了预处理器来书写代码,并使用新版本的es6语法。但是目前浏览器并不支持直接解析这些内容。所以我们需要构建化工具来处理从 Pug 生成 HTML,从 SCSS 生成 CSS,把 es6 语法的 JavaScript 转换成 es5 语法。对于 SPA 网站推荐使用webpack,而对于普通网站的构建推荐使用Gulp。这里区别开的原因是,webpack必须指定入口文件,但是Gulp只需要指定需要处理的文件或文件夹就可以了,支持通配符匹配。对于多页面的传统网站来说非常便利。

# 浏览器兼容处理

这是每个前端工程师最头疼的地方了,因为每个浏览器支持程度都不一样。在使用比较新的 API 记得去Can I use查看下各个浏览器的支持情况,如果实在是需要这个功能的话,那就只能去寻找polyfill了。

参考:

Why p tag can't contain div tag