SSTI

当用户的输入数据没有被合理的处理控制时，就有可能数据插入了程序段中变成了程序的一部分，从而改变了程序的执行逻辑。
比如说

from flask import Flask
    from flask import render_template
    from flask import request
    from flask import render_template_string
    app = Flask(__name__)
    @app.route('/test',methods=['GET', 'POST'])
    def test():
        template = '''
            

                
Oops! That page doesn't exist.

                
%s

            
 
''' %(request.url)
return render_template_string(template)
    if __name__ == '__main__':
        app.debug = True
        app.run()

这段代码是一个经典的漏洞实例，漏洞在于render_template_string函数在渲染模板时使用了%s来动态的替换字符串。这也就是Jinjia2作为模版渲染引擎，将{{]}中的内容当作变量来进行解析和替换。
这里附一张其他师傅找到的框架模板结构图：

模板引擎

模板引擎（这里特指用于Web开发的模板引擎）是为了使用户界面与业务数据（内容）分离而产生的，它可以生成特定格式的文档，用于网站的模板引擎就会生成一个标准的HTML文档。
模板引擎可以让（网站）程序实现界面与数据分离，业务代码与逻辑代码的分离，这就大大提升了开发效率，良好的设计也使得代码重用变得更加容易。

模板渲染

• 前后端渲染不共用一套代码
• Server端通过PHP、Java等服务，解析模版文件，请求数据。将数据直接渲染到模版文件上，将模版文件处理为HTML
• Server端将HTML返回给浏览器
• 浏览器端解析HTML，执行JavaScript代码 简单来说呢，模板渲染又分为前端渲染、后端渲染和浏览器渲染。模板是用于从数据（变量）到实际的视觉表现（HTML代码）这项工作的一种实现手段，而这种手段不论在前端还是后端都有应用。也就是说，我们将数据，填充到模版中，然后让渲染引擎将填充的内容生成html文本，返回到浏览器中。如果说有什么好处的话，就是能够更快速的显示数据内容，提高效率。

后端渲染（SSR、服务端渲染）

后端渲染HTML的情况下，浏览器会直接接收到经过服务器计算之后的呈现给用户的最终的HTML字符串，这里的计算就是服务器经过解析存放在服务器端的模板文件来完成的，在这种情况下，浏览器只进行了HTML的解析，以及通过操作系统提供的操纵显示器显示内容的系统调用在显示器上把HTML所代表的图像显示给用户。简单来说就是使用 JS 来渲染页面大部分内容，代表是现在流行的 SPA 单页面应用。
后端渲染的优势：

• 首屏性能。服务端渲染不需要先下载一堆 js 和 css 后才能看到页面（首屏性能）
• SEO
• 服务端渲染不用关心浏览器兼容性问题（随意浏览器发展，这个优点逐渐消失）
• 对于电量不给力的手机或平板，减少在客户端的电量消耗很重要

通俗点来说，后端渲染的实现就是网页在服务器渲染完成，再返回给浏览器，网页是在服务器端进行渲染，而不是在浏览器端进行渲染。
那么后端渲染的弊端又是什么：

• 前后端杂揉在一起，不方便本地开发、本地模拟调试，也不方便自动化测试
• 前端被约束在后端开发的模式中，不能充分使用前端的构建生态，开发效率低下
• 项目难以管理和维护，也可能会有前后端职责不清的问题。
• 后端渲染结束之后，需要进行网络传输的体积增大，带来的网络损耗和网络传输时间问题，这也就是我们经常遇到的页面白屏的问题

前段渲染（SPA、单页面应用）

前端渲染就是指浏览器会从后端得到一些信息，这些信息或许是适用于题主所说的angularjs的模板文件，亦或是JSON等各种数据交换格式所包装的数据，甚至是直接的合法的HTML字符串。这些形式都不重要，重要的是，将这些信息组织排列形成最终可读的HTML字符串是由浏览器来完成的，在形成了HTML字符串之后，再进行显示。
当我们从浏览器输入一个url的时候，浏览器会将我们输入的url发送到服务器上，然后再从服务器返回html+css+js(js代码由浏览器执行)。然后我们的客户端，也就是我们的浏览器再通过Ajax请求（API），然后服务器接收请求返回数据，浏览器接收到数据后再进行动态渲染，局部刷新页面，这就是我们的前端渲染。
特点：

• 局部刷新，无需每次都进行完整页面请求
• 懒加载。只加载可视区域数据，滚动后加载其它数据
• 富交互。使用 JS酷炫效果
• 节约服务器成本。省电省钱，支持 CDN 部署，服务端渲染时间减小
• 天生的关注分离设计
• http response大小也会减少
• JS一次学习，到处使用。Web、Serve、Mobile、Desktop

同样前端渲染也存在弊端：

• 可能会增加HTTP请求
• 只能使用客户端静态数据，不如后台模板来得强大。
• 对搜索引擎不友好。
• 即使资源缓存了，仍然需要js运行一遍来生成界面，这样比浏览器直接渲染缓存的资源要慢。

同构渲染

同构渲染指前后端共用 JS，首次渲染时使用 Node.js 来直出 HTML。一般来说同构渲染是介于前后端中的共有部分。
所谓同构，简单的说就是一份代码，即能进行服务端渲染（server-side rendering => ssr）,也能通过客户端来渲染（client-side rendering => csr）。
而同构渲染，则是一种渲染方案。它是指，服务端先通过 SSR，生成 html 以及初始化数据，客户端拿到代码和初始化数据后，通过对 html 的 dom 进行 patch 和事件绑定，即客户端激活（client-side hydration => csh）。
优势：

1. 有助于 SEO
2. 共用前端代码，节省开发时间
3. 提高首屏性能 问题：
4. 性能，大量计算性能低、个性化的缓存无法实现
5. 不容忽视的服务器端和浏览器环境差异（前后端渲染不一致）
6. 内存溢出
7. 异步操作
8. simple store（redux）

结论：总的来说，同构渲染实施难度大，不够优雅，无论在前端还是服务端，都需要额外改造。

实例1

说完了具体的模版引擎和渲染，简单的举一个例子 首先定一个模版

  

    
{$what}


    

其中{$what}为数据，如果想渲染到代码中，渲染完成以后

    
decease

那么{$what}参数又是如何进行传递的呢？这就需要结合使用的模版引擎进行分析。如果使用的模版引擎为smarty。想要传递的话，js代码就可以这样

var tpl= new jSmart(tplStr);//tplStr就是模板的字符串。
var content = "Hello World";
tpl.fetch({what:content});

其他的就是由模版引擎来进行渲染执行了。

实例2

创建模版文件test.tpl

    {%$a%}

后端设置变量：

$smarty->assign('a', 'give data');

展示模板：

$smarty->display("test.tpl");

经过渲染之后，到前端就会变成

    give data

这种方式的特点是展示数据快，直接后端拼装好数据与模板，展现到用户面前。

为何需要服务器模版

为什么HTML代码和应用程序逻辑混合在一起不好，假如你使用下面的代码为你的用户提供服务：