【web漏洞百例】2.路径操纵、密码硬编码

一、路径操纵
描述:

通过用户输入控制file System操作所用的路径,借此攻击者可以访问或修改其他受保护的系统资源。

举例:
当满足以下两个条件时,就会产生“路径操纵”错误:
1.攻击者能够指定某一file system操作中所使用的路径。
2.攻击者可以通过指定特定资源来获取某种权限,而这种权限在一般情况下是不可能获得的。

例如,在某一程序中,攻击者可以获得指定的权限,以重写指定的文件或是在其控制的配置环境下
运行程序。

例1:下面的代码使用来自于HTTP请求的输入来创建一个文件名。程序员没有考虑到攻击者可能使用
像“../../tomcat/conf/server.xml”一样的文件名,从而导致应用程序删除它自己的配置文件。
String rName=request.getParameter("reportName");
File rFile=new File("/usr/local/apfr/reports/"+rName);
...
rFile.delete();

例2:下面的代码使用来自于配置文件的输入来决定打开哪个文件,并返回给用户。如果程序在一定
的权限下运行,且恶意用户能够篡改配置文件,那么他们可以通过程序读取系统中以.txt拓展名结尾
的所有文件。
fis=new FileInputStream(cfg.getPropert("sub")+".txt");
amt=fis.read(arr);
out.println(arr);

解决方案:
防止“路径操纵”的最佳方法是采用一些间接手段:例如创建一份合法资源名的列表,并且规定
用户只能选择其中的文件名。通过这种方法,用户就不能直接由自己来指定资源的名称了。

但在某些情况下,这种方法并不可行,因为这样一份合法资源名的列表过于庞大、难以跟踪。因此,
程序员通常在这种情况下采用黑名单的方法。在输入之前,黑名单会有选择地拒绝或者避免潜在
的危险字符。但是,任何这样一份黑名单都不可能是完整的,而且将随着时间的推移而过时。
更好的方法是创建一份白名单,允许其中的字符出现在资源名称中,且只接受完全由这些被认可
的字符组成的输入。

小贴士:
1.程序在执行输入校验时,应确保验证无误,且使用Custom Rules Editor(自定义规则编辑器)为
该验证例程创建适当的规则。

2.执行本身有效的黑名单是一件非常困难的事情,因此如果验证逻辑完全依赖于黑名单的方法,那么
有必要对这种逻辑进行质疑。鉴于不同类型的输入编码以及各种元字符集在不同的操作系统、数据库
或其它资源中可能有不同的含义,确定随着需求的不断变化,黑名单能否方便、正确、完整地进行更
新。



二、密码硬编码
描述:

“密码硬编码”会削弱系统安全性,并且无法轻易修正出现的安全问题。

举例:
使用硬编码方式处理密码绝非好方法。这不仅是因为所有项目开发人员都可以使用通过硬编码方式
处理的密码,并且还会使这一问题变得及其困难。一旦代码投入使用,除非对软件进行修补,否则您
再也不能改变密码了。如果账户中的密码保护减弱,系统所有者将被迫在安全性和可行性之间做出
选择。

例1:一下代码使用硬编码来连接数据库
...
DriverManager.getConnection(url,"scott","tiger");
...
改代码可以正常运行,但是任何有该代码权限的人都能得到这个密码,一旦程序发放,将无法更新
数据库"scott"和密码"tiger",除非是要修补该程序。心怀不轨的雇员可以利用手中掌握的信息访问
权限入侵系统。更糟的是,如果攻击者能够访问应用程序的字节代码,那么他们就可以利用javap -c
命令访问已经过反编译的代码,而在这些代码中恰好包含着用户使用过的密码值,我们可以从一下
看到上述例子的执行结果:
javap -c ConnMagr.class
22:ldc #36;//String jdbc:mysql://ixne.com/rxsql
24:ldc #38;//String scott
26:ldc #17;//String tiger

解决方案:
绝对不能对密码进行硬编码。通常情况下,应对密码加以模糊化,并且在外部资源文件中进行处理。
在系统中采用明文的形式存储密码,会造成任何有充分权限的人读取和无意中误用密码。至少,密码
要先经过hash处理再存储。

有些第三方产品宣称可以采用更加安全的方式管理密码。例如,WebSphere Application Server4.x
用简单的异或加密算法加密数值,但是请不要对诸如此类的加密方式给予完全的信任。WebSphere以及
其它一些应用服务器通常只是提供过期的且相对较弱的加密机制,这对于安全性敏感的环境来说是远远
不够的。一般较为安全的解决方法是采用由用户创建的所有者机制,而这似乎是目前最好的办法。

小贴士:
1.可以使用Fortify Java Annotation、Fortify和FortifyNotPassword来指示哪些字段和变量代表密码。

2.识别null password、empty password和密码硬编码时,默认规则只会考虑包含password字符的字段
和变量。但是,使用Custom Rules Editor(自定义规则编辑器)提供的password Management(密码管理)
向导可轻松创建能够从自定义字段和变量中检测出密码管理问题的规则。
转载请注明出处:http://blog.csdn.net/acmman/article/details/66969805
  • 1
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
在应用程序的配置文件(如application.yml)中,避免硬编码账号密码可以采取以下方法: 1. 使用环境变量:将账号和密码存储为环境变量,然后在应用程序的配置文件中引用这些环境变量。这样可以将敏感信息与代码分离,提高安全性。 例如,在application.yml中使用`${ENV_VAR_NAME}`来引用环境变量。您可以在运行应用程序之前设置这些环境变量,或者使用配置管理工具(如Docker、Kubernetes等)来传递环境变量。 ```yaml datasource: url: jdbc:mysql://localhost:3306/mydb username: ${DB_USERNAME} password: ${DB_PASSWORD} ``` 2. 使用加密配置:将账号和密码加密,并将加密后的值存储在配置文件中。然后,在应用程序中使用相应的解密机制来获取明文值。这可以防止明文密码泄露。 例如,您可以使用Spring Boot的加密功能(如Jasypt)来对敏感配置进行加密和解密。 ```yaml datasource: url: jdbc:mysql://localhost:3306/mydb username: ENC(encryptedUsername) password: ENC(encryptedPassword) ``` 3. 使用外部配置文件:将账号和密码存储在一个独立的配置文件中,然后在应用程序启动时通过命令行参数或其他方式指定该配置文件的位置。这样可以将敏感信息与代码分离,并且可以更容易地进行配置管理。 例如,在启动应用程序时使用`--spring.config.location`参数指定外部配置文件的位置。 ``` java -jar myapp.jar --spring.config.location=file:/path/to/config/application.yml ``` 无论您选择哪种方法,请确保对配置文件和敏感信息进行适当的保护和访问控制,以防止未经授权的访问。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

光仔December

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值