"heap spraying"维基百科文章表明，许多javascript漏洞涉及将shellcode定位在脚本的可执行代码或数据空间内存中，然后让解释器跳转并执行它。我不明白的是，为什么解释器的整个堆可以标记为＆＃34;数据＆＃34;因此DEP会阻止解释器执行shellcode吗？同时，javascript派生字节码的执行将由虚拟机完成，该虚拟机不允许它修改属于解释器的内存（这不会在V8上工作，似乎执行机器代码，但可能适用于使用的Firefox某种字节码。）
我猜上面的内容听起来微不足道，而且可能很多事实上已经完成了。所以，我试图了解推理中的缺陷或现有解释器实现中的缺陷。例如。当javascript要求内存时，解释器是否依赖于系统的内存分配而不是实现自己的内部分配，从而使得分离属于解释器和javascript的内存过于困难？或者为什么基于DEP的方法不能完全消除shellcode？
答案 0 :(得分：4)
要回答您的问题，我们首先需要定义数据执行预防，及时编译和 JIT Spraying 。
数据执行保护是一项安全功能，禁止从非可执行内存区域执行代码。 DEP可以通过硬件机制（如NX位）和/或软件机制通过添加运行时检查来实现。
及时（JIT）编译器是动态编译器，它将运行时的字节代码转换为机器代码。目标是结合解释代码的优点和编译代码的速度。只有在编译中花费的额外时间可以通过编译代码所期望的性能增益来分摊时，它才应该编译方法。 [1]
JIT spray 是强制JIT引擎写入许多带有嵌入式shellcode的可执行页面的过程。
[...]
例如，诸如“var x = 0x41414141 + 0x42424242;”之类的Javascript语句可能被编译为在可执行映像中包含两个4字节常量（例如，“mov eax，0x41414141; mov ecx，0x42424242; add eax ，ecx“）。 通过在这些常量的中间开始执行，会显示完全不同的指令流。
[...]
关键的见解是JIT是可预测的，必须将一些常量复制到可执行页面。给定一个统一的语句（例如长和或任何重复模式），这些常量可以编码小指令，然后控制流到下一个常量的位置。 [2]
超出本答案范围的高级技术必须用于查找JIT喷涂块的地址并触发漏洞利用。
现在应该很清楚
如果攻击者的代码是由JIT引擎生成的，它也将驻留在可执行区域中。换句话说，DEP不参与JIT编译器发出的代码的保护。 [3]
<强>参考
[1] A Dynamic Optimization Framework for a Java Just-in-Time Compiler
[2] Interpreter Exploitation: Pointer Inference and JIT Spraying