jsp文件怎么打开方式(手机有什么app能看jsp)

升级错误日期以获取代码执行

照片:乔希·索伦森

几周前，当我即将完成萨尔大学的申请时，一杯新鲜的茶正放在我的桌子上。在我的初始申请被接受后，我被要求上传一些额外的文件，如我的护照，以完成这一过程。因此，我被转发到一个上传平台，我应该使用我的申请人ID和我的生日作为密码登录。但是，我生日不行，被拒绝登录。这是一个关于错误的出生日期如何导致代码在大学服务器上执行的故事。

你不可以过去？

生日没被当密码后，我喝了一大口茶，思考下一步。最后，当网站不适合我的时候，我做了我一直做的事情:我分析了网站的流量！

登录页面需要申请人ID和生日。

下面显示的流量显示，当我单击login按钮时，应用程序向loginBewerber端点发送一个请求，该请求在URL中包含申请人的ID，在请求正文中包含生日。而ID和生日都是用户提供的输入，我们可以使用并尝试操作。我尝试的第一个操作是使用典型的SQL注入(SQLi)绕过日期检查:01 . 02 . 1999 & # 34；+或+& # 34；1"="1.通过这种攻击，攻击者可以滥用SQL的语法。在这种情况下，我错误地验证了生日检查条件，并希望服务让我登录。出乎我意料的是，攻击第一次就成功了，服务器的回答提供了一个XML，里面包含了我的很多个人信息，比如我的地址，性别，出生日期。后来我也知道了日期检查只是一个客户端，任何密码都提供XML。

登录请求在URL中包含申请人的ID，在请求正文中包含生日。登录请求返回包含大量个人信息的XML。

很快，我检查了这个XML中的所有信息，并找到了我最初登录尝试失败的原因:不幸的是，管理员为我的帐户存储了错误的生日。至少，我得到了正确的日期并通过了登录。

我对此有不好的预感

当时很好奇这个应用还能提供什么。毕竟，我被要求将我的护照上传到该服务。如果不绕过认证，把重要文件上传到只保证申请人生日的应用已经是一种不安的感觉了。我是说，强求一个标准学生的生日需要多久？但现在，随着已知的脆弱性，这种感觉更糟糕。

当我在登录网址中查看申请人的ID时，这种感觉得到了进一步的证实。不用专业黑客也能看出来申请人的身份证只是一个普通号码。在我的例子中，数字是45678。如果我从ID中减去1并再次发送请求，会发生什么情况？答案很快就来了，我差点被茶呛到:其他用户的个人信息都显示在我的屏幕上。

我的屏幕显示申请人45677的信息，同样的请求适用于所有其他id。虽然我的真实身份证不是45678，但是号码在同一个地区。因此，这意味着任何人都可以自由访问近5万条个人用户信息，如家庭住址、电子邮件等；作为这个平台的用户，我不是很开心。

是时候上传一些文件了

现在我可以登录我的用户帐户，我可以开始上传要求的论文。然而，我不想将我的个人文档上传到这项服务，这并不奇怪。然而，我的好奇心被激起了，因为我想知道上传功能是如何工作的。所以我发出了一些测试文件。

流量分析揭示了一个奇怪的上传过程，它由两个请求组成。首先，如下所示，发送一个简单的post请求来上传文档。以下示例要求URL包含文件名，正文包含内容。一旦第一个请求被接受，服务器将用包含文档存储路径的纯文本进行响应。接下来，客户端发送另一个请求，将上传的文件链接到相应的应用程序。在下面的第二个请求示例中，我们在URL中找到申请人的ID，在file_renamed参数中找到前一个请求的文件名。最后，该服务将上传的文档列为用户应用程序的一部分。

上传请求在其URL中包含文件名和部分路径。上传流程的第二部分发送一个请求，将文件与相应的申请者联系起来。

我以前见过类似的上传过程。因此，关于这个上传过程的两个方面引起了我的注意:首先是初始URL包含文件名和服务器存储文件的路径的其他部分。如果我们分析URL参数并将它们的值与我们从服务器获得的响应文本进行比较，我们可以看到这一点:文件保存为/data/uploader/uploads/20221/45678 _ 2022 _ 01 _ 31 _ 22 _ 21 _ 18 _ 2 _ passport _ hantke _ florian.pdf。如果我们操纵这条道路会发生什么？

第二个奇怪之处是，只要file_renamed参数没有指向一个现有的文件，createUploadFile请求就会返回一个带有信息堆栈跟踪的错误消息。我们可以使用关键信息进行进一步分析！让我再喝一口茶，然后我们继续。

从第二次请求提供堆栈跟踪开始，我首先考虑了各种方法来进一步升级这个缺陷。栈跟踪不仅揭示了有用的信息，比如源代码的结构，还回复了file_renamed参数的值。因为file_renamed参数是XML结构的一部分，所以我尝试的下一个攻击是XML外部实体(XXE)注入。这种攻击滥用XML中的外部实体来发送服务器端请求，或者将文件内容或目录列表加载到XML结构中，就像我在我们的示例中所做的那样。如下面的请求所示，我将实体X定义为包含/etc/passwd文件的内容。然后，服务器使用这个实体作为file_renamed参数的内容。因为此内容不是有效的文件名，所以服务器将使用包含无效文件名的错误消息来响应-/etc/passwd的内容。因此，这意味着我们可以读取所有允许用户访问的目录和文件——不仅是标准的Linux文件，还可以读取用户上传的应用程序或文件的源代码。

上传请求易受XXE攻击。易受攻击的请求会在错误消息中返回/etc/passwd的内容。

接下来我继续分析第一个讨论的奇怪之处，即来自上传请求的路径参数。如前所述，来自服务器的响应将提供关于文件存储位置的反馈。有了这个提示，我很快发现端点容易受到路径遍历攻击。路径遍历攻击允许黑客在不检查服务器有效性的情况下操纵路径。在这种情况下，它允许我将上传的文件存储在服务器上我想要的任何位置。但这只是冰山一角，因为我发现了一个更具破坏性的事实:服务器从不检查文件内容和文件扩展名。因此，服务器为更严重的攻击打开了大门。

糟糕，我执行代码了吗？

喝完最后一口茶，我想到了一个利用任意文件上传漏洞的方法。当然，我可以覆盖配置文件或上传一个HTML文档来触发XSS。然而，我有一个更好的主意。

从上面提到的错误消息中，我们知道web服务器是基于Java的。因此，我想我可以执行JavaServer Pages (JSP)文件。允许JSP Web开发人员编写包含在服务器端执行的动态Java部件的HTML代码。这意味着控制服务器加载的JSP文件的攻击者也可以在服务器端执行任意代码。

既然我找到了上传任意文件的方法，我也可以上传JSP文件。然而，有一个问题仍然不清楚:我如何诱导服务器执行文件？通常，要触发JSP文件，必须用浏览器打开文件路径。在这种情况下，初始上传目录位于webroot之外，这意味着我不能简单地请求文件路径。幸运的是，我可以使用文件上传请求中的路径遍历将文件存储在任何我想要的位置，因此它也可以存储在web目录中。除此之外，应用还提供了更直接的加载任意文件的解决方案——一个容易被路径遍历的链接，让我可以从任意路径加载文档:https:
//www . LSF . uni-Saar land . de/uploader/upload？文件=../../../../etc/passwd & folder =上传& SEM = 20221。实际上，我可以自由地加载上传的JSP文件并执行它。

为了测试我的想法，我上传到服务器的第一个(也是唯一一个)JSP文件是一个美丽而秘密的名字9187 b 2784 c 1298 7bpnwoleivsal.jsp(见下文)。然而，这不是007，这只是一个测试，一个证明代码有效执行的数学函数。当然，它确实有效。理论上，我可以在服务器上执行任意代码。到现在，你们可能都知道这意味着什么:我不仅可以读取用户上传的所有文件，还可以尝试进一步提升权限，获得root权限并超越服务器，或者从内部进一步探索大学网络。这对我来说足够了，因为我不想在第一天之前让任何人生气——是时候开始报道了。

上传请求不检查文件扩展名或内容。请求上传一个JSP测试文件。

加载JSP文件时，服务器端会产生随机数。

报告！

在我开始写报告之前，我总是做同样的心理练习。我往后一靠，思考一群不法分子发现这样的安全漏洞后会获得的潜在利润，以及对用户和组织的影响。在这种情况下，犯罪分子可以利用第一个发现的漏洞绕过初始身份验证检查，以任何用户身份登录，即使他们没有任何有效的申请人帐户。一旦他们打开了门，他们就可以上传一个JSP文件来打开一个反向外壳。到那时，他们已经中了彩票:他们不仅可以窃取近5万人的个人信息，还可以接管整个应用程序，甚至服务器。

鉴于这些明确的事实，当天晚上我很快就完成了漏洞报告，于是第二天就给大学的数据中心发了邮件。我告诉他们我的发现，不久之后，应用程序离线，只提示我一个403页面。终于收到Hochschul-IT-Zentrum (hiz)的邮件，告诉我他们可以确认调查结果，正在调查问题。此外，我们通过电话友好地了解了情况。

报告错误一天后，就无法再访问文件上传程序了。

在写这篇文章的时候，情况还是一样的。我还看到403页。然而，我知道hiz致力于解决上述问题，并已下令进行渗透测试，以检查应用程序，然后再将其重新上线。此外，为了避免类似的问题，将来会有一个已建立的外部程序来取代自实现的服务。

一个深刻的问题

现在，报告已经完成，案件已经结案。我拿起茶杯进了厨房，一边还在想这个案子，一边纳闷这些基本的安全问题怎么一直存在。当然，将错误归咎于某些开发人员总是很容易的，但是，在我看来，问题比那些编写糟糕代码的人更严重。本文概述的事实以及许多其他事实(Zerforschung，CCC)向我们表明，问题在于德国对IT安全普遍缺乏了解，这一点仍然远远落后。仅仅是单独清理每个应用，比如一遍遍清理茶杯，是解决不了的。从长远来看，这种清洁程序对茶杯非常有效，但显然不适合应用。
因此，这个深刻的问题只能通过政治手段来解决！亚瑟·温·皮内罗曾经写道，“在英国社会，有茶的地方，就有希望”。所以，我相信这也适用于德国社会。由于我已经在泡茶了，我希望这篇文章中讨论的这些基本问题在未来几乎不存在。因此，在最后一节中，我想就如何提高德国的整体IT安全性以及如何促进对这一重要问题的更多了解提出我的想法。

我之前说过，写容易出错的软件，不仅仅是开发者的错。通常，项目期限的压力会导致开发人员优先考虑其应用程序的关键功能，而不是其应用程序的安全性。例如，在新冠肺炎疫情期间，许多公司希望成为市场上第一个拥有特定产品或服务的公司，因此他们可能忽略了产品的安全性(即电晕测试中心)。由于进入成本低，行业竞争激烈，产品流失更快，错过新趋势的成本远远超过坏软件的成本。现行联盟协议中IT安全部分的一句话试图控制这种肆意妄为的行为:“制造商必须对其产品中IT安全漏洞的疏忽所造成的损害负责”。作为一个IT安全人士看这篇文章，一开始听起来很有希望，但细想就会让人大失所望。该声明表明，只有在最坏的情况下，如果犯罪黑客成功攻击应用程序并造成损害，制造商可能会付出非常高的代价。在我看来，作为一个法律和政治的业余爱好者，这种思维方式似乎是错误的，必然会让应用的用户付出代价。如果我们总是等待最坏的情况，伤害已经发生了。当然，我们也有GDPR，但老实说，以我有限的法律知识，我不知道漏洞的存在是否应该受到惩罚，我也从未听说过任何这样的先例。在我看来，政府需要对独立安全研究人员报告的安全漏洞实施严格的执法和更明确的处罚，甚至在它们开始被犯罪分子滥用之前。

话虽如此，错误并不一定只能由独立研究者或罪犯发现。显然，公司可以也应该检查自己的安全性。此外，他们应该依靠专业的外部渗透测试，因为测试人员经常从另一个角度看待应用程序。事实上，正如联盟协议的IT安全部分所述，政府机构已经计划进行频繁的测试。但是，在我看来，这也应该包括所有的公共机构，比如大学，因为人们相信它们是安全的。更重要的是，它应该进一步包括在德国经营的所有公司。

渗透之外的另一个方面是提高一般的IT安全知识。在开发软件之前，人们至少需要对软件开发中的安全最佳实践有一个简单的了解。比如，在你成为厨师之前，你需要获得官方的健康证明，这样你才知道如何不毒害你的客人。在为你的公司开卡车之前，你需要一个特别的许可证，这样你就不会撞坏你的车。为什么你不需要一个开发者许可证，这样你就不会毒害你的应用程序的用户或者使你的软件崩溃？虽然这样的许可证对于软件开发来说不现实，但是安全教育才是！安全课程必须是每个IT教育的重要组成部分。此外，

最后，我的最后一个想法是联盟协议的另一个方面:“在一个负责任的过程中，如IT安全研究，识别、报告和关闭安全漏洞，在法律上应该是可行的”。这是一个很重要的事实！目前，即使你的个人数据面临风险，在应用程序中寻找漏洞也是一个灰色地带。还好我还没遇到什么问题，公司总是很高兴我举报他们的漏洞。然而，情况并非总是如此，因为其他例子强调了作为罪犯的安全专业人员的滥用。漏洞测试的法律方面并不完全清楚，这使得人们不敢研究他们使用的产品。如果流程定义明确且合法，将会有更多人检查产品并报告漏洞。我们刚刚见证了一个很好的例子:我的意思是，为什么近5万名大学生登录一个上传门户(这看起来已经很可疑了)却没有人发现或报告这些基本问题？负责任的漏洞研究是公共服务，必须合法化！

通过最后的声明，我希望你能同意我们的教育和法律机构必须改变一些事情，以创造一个更安全的互联网和世界。感谢您的阅读。现在，喝杯茶，为你余下的一天带来一点希望。