Android 应用程序面临哪些十大安全威胁?

发布于 2024-12-29 03:11:52 字数 664 浏览 2 评论 0原文

我知道这个问题本质上可能有点恶意,但我只是想学习 Android/移动应用程序开发的最佳实践,而安全性绝对是软件中的一个大问题。如果您在阅读此问题 (!) 后仍然认为它本质上是恶意的,请记住,我不是在问如何实施任何这些攻击,我只是在问 >优秀的 Android/移动开发人员需要认识到其中的攻击。

以下是应用程序的“官方”OWASP 十大安全威胁列表(链接位于此处< /a>)。我想知道其中哪些(如果有)适用于 Android 开发,或者是否还有此处未列出的其他主要攻击:

  • 注入
  • 跨站点脚本(XSS)
  • 破坏身份验证和会话管理
  • 不安全直接对象引用
  • 跨站点请求伪造( CSRF)
  • 安全配置错误
  • 不安全的加密存储
  • 未能限制 URL 访问
  • 传输层保护
  • 不足 未经验证的重定向和转发

请注意:我不是在谈论为在移动设备中显示而构建的网站设备。我说的是部署在移动设备上的实际应用程序。对于 Android,这意味着 APK

I know this question may seem a bit malicious in nature, but I'm just trying to learn best practices in Android/mobile app development, and security is definitely a big issue in software. If you still, after reading this question (!), think it is malicious in nature, just keep in mind I'm not asking how to implement any of these attacks, I'm just asking which attacks a good Android/mobile developer needs to be cognizant of.

Below is a list of the "official" OWASP Top 10 security threats for applications (link is here). I was wondering which of these (if any) apply to Android development, or if there are any other major attacks not listed here:

  • Injection
  • Cross-Site Scripting (XSS)
  • Broken Authentication and Session Management
  • Insecure Direct Object References
  • Cross-Site Request Forgery (CSRF)
  • Security Misconfiguration
  • Insecure Cryptographic Storage
  • Failure to Restrict URL Access
  • Insufficient Transport Layer Protection
  • Unvalidated Redirects and Forwards

Please note: I'm not talking about websites that are built for being displayed in mobile devices. I'm talking about actual applications that are deployed on mobile devices. In the case of Android, this means APKs.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

半葬歌 2025-01-05 03:11:52

OWASP 前十名适用于 Web 应用程序,而 Android 应用程序则不同。

然而,OWASP 确实有一个快速增长的移动计划,他们目前正在努力跻身移动前十名。以下是今年前十名候选者的列表:

  1. 不安全的数据存储
  2. 薄弱的服务器端控制
  3. 传输层保护不足
  4. 客户端注入
  5. 糟糕的授权和身份验证
  6. 不正确的会话处理
  7. 通过不受信任的输入进行安全决策
  8. 侧通道数据泄漏
  9. 损坏的加密技术
  10. 敏感信息

泄露是 一组精彩的幻灯片,详细解释了这些内容。

除了 OWASP 移动十大之外,我还可以向您介绍Android 平台的应用程序安全性,O'Reilly 于 2011 年 12 月刚刚发布,讨论了 Android 上当前的安全移动应用程序设计,并讨论了该平台继承的威胁以及如何以安全的方式编写应用程序以避免这些威胁(免责声明:我是这本书的作者:))。

The OWASP Top Ten is intended for web applications and Android apps are different.

OWASP does, however, have a fast-growing mobile intitiative and they are presently working on the Mobile Top Ten. Here is a list of the candidate top ten for the current year:

  1. Insecure Data Storage
  2. Weak Server Side Controls
  3. Insufficient Transport Layer Protection
  4. Client Side Injection
  5. Poor Authorization and Authentication
  6. Improper Session Handling
  7. Security Decisions Via Untrusted Inputs
  8. Side Channel Data Leakage
  9. Broken Cryptography
  10. Sensitive Information Disclosure

There is a wonderful set of slides that explain these in great detail.

In addition to the OWASP Mobile Top Ten, I can point you to Application Security for the Android Platform, just published by O'Reilly in December 2011 that discusses current secure mobile application design on Android, and provides a discussion about the threats inherit to that platform and how to code apps in a secure manner to avoid them (disclaimer: I'm the author of this book :)).

枕头说它不想醒 2025-01-05 03:11:52

很难具体回答你的问题,因为从你发布的内容来看,你对你的 Android 应用程序和你的 Java 服务器感到好奇,但你问的是一个非常普遍的问题。 OWASP 发布的大部分内容都非常高水平,因此如果不了解 Android 应用程序和服务器工作的具体情况,将很难获得任何真正的实质性答案。一般来说,当人们可以攻击服务器并拥有通过所有手机而不仅仅是一部手机传输的所有数据时,他们就不会攻击手机。

所以注入、XSS、CSRF等大多适用于服务器端。如果您的程序使用 Android SQLite 数据库,您可以执行注入(请参阅此处的应用程序细节如何发挥作用)。如果您的应用程序是基于 Web 的客户端,或者将 WebView 用于其中的任何部分(同样具体情况很重要),则 XSS、CSRF 可能适用。

通过使用PreparedStatements/PreparedCall,可以轻松修复Java 服务器上的注入。不要使用声明。如果您使用 JPA、Hibernate、iBatis,那么它们中的大多数都在底层使用了PreparedStatements。 Java 应用程序中的注入很容易阻止这些攻击:

https://www.owasp.org/index.html php/Preventing_SQL_Injection_in_Java

XSS 和 CSRF 更难,但可以使用过滤器来阻止。仔细阅读此页,您将看到哪里有另一个描述该项目的链接。

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_ (CSRF)_Prevention_Cheat_Sheet

通过不安全的连接发送密码。如果您通过 HTTP 或非 SSL 套接字发送密码,那么您将泄露太多信息(使用单向哈希没有帮助,因为我不需要知道密码。我需要的只是哈希并且是明文传输的)。因此,请确保您使用 SSL 来验证用户身份。然后我们可以了解您如何将这些密码存储在数据库中。您使用的是单向哈希吗?你在使用 bcrypt 吗?如果没有,您是否使用 SALT?您是否迭代哈希以增加破解该哈希所需的时间?

大多数入侵涉及通过操作系统、数据库、SQL 注入等漏洞来访问底层数据库。获取存储用户和密码的表。然后使用简单的现成显卡运行超快速的暴力破解方法来暴力破解密码。如果您不注意适当保护您的密码,现在大多数单向哈希都可以使用此方法被破解。

It's hard to answer your question in specifics because from what you've posted you are curious about your Android Application and your Java server, but you're asking a very generic question. Much of what the OWASP has published is very high level so getting any real substantive answers is going to be hard without knowing the specifics of how your Android application and server work. Generally, people aren't going to attack a phone when they can go after the server and own all of the data that will pass through all of the phones not just a single handset.

So injection, XSS, CSRF, etc mostly apply to the server side. You could perform injection into the Android SQLite database if your program uses it (see how the specifics of your app come into play here). XSS, CSRF could apply if you app is a web based client, or using webview for any part of it (again specifics matter).

Injection on the server for Java can easily be remedied by using PreparedStatements/PreparedCall. Don't use Statement. If you're using JPA, Hibernate, iBatis most of these use PreparedStatements under the hood. Injection in Java apps is easy to thwart those attacks:

https://www.owasp.org/index.php/Preventing_SQL_Injection_in_Java

XSS and CSRF are harder, but can be prevented using a filter. Read down this page, and you'll see where there is another link to the project that describes it.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Sending passwords over an insecure connection. If you send a password over HTTP or non-SSL socket then you're going to be disclosing too much information (using one-way hashes doesn't help because I don't need to know the password. All I need is the hash and that's transmitted in the clear). So make sure you are using SSL for authenticating users. Then we can get into how you are storing those passwords in your database. Are you using a one-way hash? Are you using bcrypt? If not are you using SALTs? Are you iterating on the hash to increase the time it takes to break that hash?

Most break-ins involve getting access to the underlying database through vulns in the OS, database, SQL injection, etc. Grabbing the table storing the user and passwords. Then run a super fast brute force method using simple off the shelf graphics cards to brute force passwords. Most one-way hashes can be broken today using this method if you don't take care to protect your passwords appropriately.

成熟的代价 2025-01-05 03:11:52

对于(Android)应用程序,大多数提到的攻击并不经常发生。

如果您愿意让我们知道您的情况中谁是Alice鲍勃夏娃有人可能会为您的问题提供真正的答案,所以:

  • 谁需要受到保护?
  • 谁会(想要)攻击​​您应用程序的安全性?

我能自发想到的最现实的威胁(由于缺乏信息,我假设设备上有一个几乎独立的应用程序)将是您的应用程序中的一个错误,它要么

  • 将(应用程序)私人信息泄漏到非安全存储,或者
  • 允许通过用户输入注入恶意数据(阅读:SQL 注入;但一般问题不仅与 SQL DB 相关;例如,考虑“XML 注入”)。

编辑:

让我们收集一些应用程序安全方面可能的利益相关者(没有任何特定顺序):

  • 应用程序用户:他、他的数据、他的货币价值或他的隐私是否需要受到保护/应用程序支持吗?

  • 应用程序用户:他是否对应用程序和/或开发人员的任何资产构成威胁?

    应用程序用户:他是否对应用程序和/或开发人员的任何资产

  • 应用开发者:他或他的知识产权或其他与应用相关的资产是否需要通过应用的设计进行特别保护?

  • 应用程序开发人员:他或他的环境是否会对不属于他的任何资产构成威胁?

  • 第三方:是否存在其知识产权或其他价值需要保护的第三方?

  • 第三方:是否有第三方可能有兴趣损害上述任何可能不受威胁的资产的安全?

(如果您愿意,可以添加更多。)

For (Android) Apps, most of the mentioned attacks do not apply regularily.

If you care to let us know who, in your case, is Alice, Bob, or Eve someone may provide a real answer to your question, so:

  • Who needs to be protected?
  • Who would (want to) attack the security of your App?

The most realistic threat I can come up with spontaneously (for a lack of information I assume a pretty much standalone App on a device) would be a bug in your App which either

  • leaks (app-)private information to a non-secure storage, or
  • allows injection of malicious data via user input (read: SQL injection; but the general problem is not only related to SQL DBs; think, e.g., about "XML injection").

Edit:

Let's just collect some possible stakeholders in the App's security (without any particular order):

  • App user: Does he, his data, his monetary values, or his privacy need to be protected/supported by the App?

  • App user: Does he pose a threat to any asset of the application and/or the developer?

  • App developer: Does he, or his IP, or other application-related assets, need to be specifically protected by the design of the application?

  • App developer: May he or his environment pose a threat to any asset not belonging to him?

  • Third party: Is there a third party whose IP or other values need to be protected?

  • Third party: Is there a third party which may be interested in compromising security for any of the above assets possibly unter threat?

(add more if you like.)

梦情居士 2025-01-05 03:11:52

许多移动设备允许应用程序弹出浏览器,并将挂钩插入浏览器,从而允许它们观察击键等。这可以允许键盘记录。攻击发生如下:

  1. 应用程序创建一个浏览器实例。
  2. 应用程序使用特权浏览器 API 将按键事件处理程序添加到浏览器加载的页面。
  3. 应用程序使浏览器加载 URL,例如银行登录表单。
  4. 使用假设浏览器同源策略正在保护他们输入的数据。
  5. 应用程序观察并窃取可能包括密码的表单内容。

如何从 iPhone 应用启动 Safari?

如何从我的 Android 网络浏览器中打开 URL应用程序?

Many mobile devices allow an app to pop-up a browser, and insert hooks into the browser which allows them to observe key-strokes and the like. This can allow key-logging. The attack occurs as follows:

  1. App creates a browser instance.
  2. App uses privileged browser APIs to add key-event handlers to pages loaded by the browser.
  3. App causes browser to load a URL, for example a bank login form.
  4. Use assumes that the browser same-origin policy is protecting the data they enter.
  5. App observes and exfiltrates form content possibly including the password.

How can I launch Safari from an iPhone app?

How can I open a URL in Android's web browser from my application?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文