Browsed by
标签: iOS

关于移动端的钓鱼式攻击

关于移动端的钓鱼式攻击

phishing-1今天,在微博上看了一篇《微信和淘宝到底是谁封谁》的文章,我觉得文章中逻辑错乱,所以,我发了一篇关于这篇文章逻辑问题的长微博。后面,我被原博主冷嘲热讽了一番,说是什么鸡汤啊,什么我与某某之流的人在一起混淆视听啊,等等。并且也有一些网友找我讨论一下相关的钓鱼式攻击的技术问题。所以,我想写下这篇纯技术文章,因为我对那些商业利益上的东西不关心,所以,只谈技术,这样最简单。

首先说明一下,我个人不是一个安全专家,也不是一个移动开发专家,按道理来说,这篇文章不应该我来写,但是我就试一试,请原谅我的无知,也期待抛砖引玉了,希望安全的同学斧正

关于钓鱼式攻击,其实是通过一种社会工程学的方式来愚弄用户的攻击式,攻击者通常会模仿一个用户信任的网站来偷取用户的机密信息,比如用户密码或是信用卡。一般来说,攻击者会通过邮件和实时通信工具完成,给被攻击者发送一个高仿的网站,然后让用户看不出来与正统网站的差别,然后收集用户的机密数据。

移动端钓鱼攻击点分析

因为钓鱼式攻击并不新鲜,所以我这里只讲移动方面的。

在移动端,这个事情会更容易干,因为移动端有如下特点:

  • 移动端的UI只能有一个应用占据整个屏幕,你只能看到一个应用,而且用户屏幕小,能显示的信息有限,比如浏览器里的网址是显示不全的。这会给钓鱼攻击有很多可乘之机。
  • 移动端的平台有其安全的设计。每个应用都是隔离开的,一个应用无法获取另一个应用的数据。而且应用的下载基本上来说都是来自合法的地方。比如iOS的设备通过App Store下载,每个程序都有自己的签名保证不会被篡改。而且移动端的的应用有各种权限配置,这样也能很大程度提高安全性。
  • 移动端的APP有些有些是收费的,所以自然会有盗版需求,虽然在平台上做了一些安全设计,但是并不完美。用户可以越狱,可以root。这给恶意软件有了可乘之机。

下面我们来分析下移动端的用户操作,我们重点关注用户控制权的切换过程(因为这是攻击点)

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (64 人打了分,平均分: 4.44 )
Loading...
DHH 谈混合移动应用开发

DHH 谈混合移动应用开发

 

1053-DHHDavid,Ruby on Rails 作者,37signals 合伙人

畅销书作家、演说家、赛车手、业余摄影师、顾家好男人

 

37signals 在2013年2月发布了 Basecamp 的 iPhone app,在此之前我们就使用原生开发(native)还是混合开发(hybrid)做了许多尝试。在2012年项目启动的时候,大多数人都倾向于原生开发。

Facebook 在2012年发布了他们新的 iOS app,为了获得更好的用户体验,他们放弃了原来的 HTML5 混合开发方式。考虑到2010~2011年的时候,HTML 在移动端的性能确实不尽如人意,这个决定在当时看来也在情理之中。2010年的时候我们觉得 iPhone 3G/3GS 够眩够快,但按照现在的标准来看它们就太慢了。因此在为移动应用开发做架构设计时,我们需要考虑新的移动设备的计算能力,而不是那些老的过时的设备。

移动开发架构设计不需要过多考虑设备的性能

我们从一些测试中得出的一个结论是:现在的移动设备计算能力都很强,运行原生应用和 HTML 应用的效果差别不大,而 HTML 开发的成本则要比原生开发小得多。

当然这个结论在某些领域并不太适用。如果你要开发一个 3D 游戏,原生开发方式能够带来更好的游戏体验。但如果你的移动应用象 Basecamp 一样侧重信息处理,为了降低开发成本,你就可以考虑混合开发方式。我们就是如此,下面是我们三代移动产品的发展轨迹:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (27 人打了分,平均分: 2.93 )
Loading...
Google Inbox如何跨平台重用代码?

Google Inbox如何跨平台重用代码?

原文链接《How Google Inbox shares 70% of its code across Android, iOS, and the Web

inbox2-640x264

开发一个移动应用在当下并不是一件容易的事情。如果想要获得最多的用户,你的应用通常需要覆盖 iOS, Android, 和 Web 三大平台。这就意味着同一个应用需要开发三个版本,使用 Objective-C 或者 Swift 开发 iOS 版本,使用 Java 开发 Android 版本,使用 JavaScript/CSS/HTML5 开发 Web 版本。工作量增大的同时也意味着有更多的 bug 需要修复。

这个问题也是 Google 在开发 Google Inbox 时致力要解决的。在最近发布的这款应用中,Google 使用了一些工具实现了70%的代码跨平台复用。

Google Inbox 覆盖 iOS, Android, Web 三个平台,它们使用的是同一个后台代码逻辑,只是前端的用户体验和平台相关特性的实现有所不同。Google 自主开发了一套辅助工具将 Android 版本的 Java 代码逻辑编译为 Objective-C (针对 iOS 平台) 和 JavaScript (针对 Web 浏览器)。 Java 到 JavaScript 的编译由 Google Web Toolkit SDK 完成,Java 到 Objective-C 的编译则由 J2ObjC (j2objc.org)来完成。

J2ObjC 是一个开源项目,由 Google 在2013年发布。Google Sheets (Google Docs 中的电子表格部分) 也使用了 J2ObjC,而 Google Inbox 则是目前使用 J2Objc 最多的 Google 项目。

Google Inbox 复用的代码逻辑包括:对话 (conversations),提醒 (reminders),联系人 (contacts)。还有网络相关功能和离线同步。这些代码逻辑的复用节省了大量的时间和成本。

在产品设计时,Google 将这些可复用功能划分为抽象的逻辑概念,比如:提醒的逻辑放在 “reminder.java” 中,可以被 Android UI 调用。对 iOS 版本而言,J2ObjC 将 “reminder.java” 编译成 Objective-C 代码,再由 iOS UI 调用。

Google 没有跨平台编译 UI 部分的代码,因为不同平台的UI特性各有不同,盲目统一会导致非常糟糕的用户体验。代码复用只是针对可以共享的后台逻辑,前端的UI实现是完全原生 (native) 的。这与 Xamarin (一个基于 Microsoft C# 的跨平台移动开发工具) 提出的概念类似。

跨平台代码复用通常会带来一些性能上的问题。Garrick Toubassi,Engineering Director 和 Google Inbox 项目组成员,对此表示: “性能上的影响如果有的话,也可以说是微不足道的。我们做过大量的性能测试。因为没有加入额外的中间层来处理跨平台兼容性,所有代码最后都是平台原生代码。J2ObjC 编译生成的目标代码和 Java 源代码拥有大致相同的对象数量和对象图谱复杂度 (object graph complexity) ”。

Google 使用的整套方法解决了跨平台移动开发中的一个很重要的问题,同时也推进了安卓先行 (Android-first) 的移动开发策略。

更多 Google Inbox 文章请猛戳 Gmail 官方博客

好烂啊有点差凑合看看还不错很精彩 (40 人打了分,平均分: 3.78 )
Loading...
10个必需的iOS开发工具和资源

10个必需的iOS开发工具和资源

界面总不是一件很容易事,尤其是iPhone/iPad的界面,做过iOS开发的程序员,一定会感到开发iPhone/iPad的界面是一件多么不容易的事。下面的文章来自10 Essential iOS Developer Tools & Resources,这个文章介绍了十个iOS开发的基础性工具和资源,其一定会很有效地帮你做iOS的开发。(在这里,我再闲扯一句,虽然Android的开发好像整整XML文件界面就出来了,其明显比iOS的开发要容易很多,但是我还是觉得iOS的生命力要强过Android,看看Android今天的应用就知道,有时候入门门槛低不是一些好事,大多数的程序员搞出来的Android代码和软件简直令人作呕,就像不是每个人都能烧得手好菜一样。(“食客与大厨”,也许偏激,但值得你我思考),又把蛋扯远了)

1. Omnigraffle + Ultimate iPhone Stencil

Omnigraffle 是一个很强大的像Microsoft Viso的一个软件,其只能于运行在Mac OS X和iPad平台之上。它曾获得2002年的苹果设计奖。在这里,你可以下载 Ultimate iPhone Stencil ,然后使用Omnigraffle 来非常快地制作你的iPhone应用的演示界面。(查看了一下Omnigraffle 的iPad版,真贵,$49.99。作者居然推荐买,TNND,一看就是托)。

Omnigraffle Link, Ultimate iPhone Stencil Link

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (11 人打了分,平均分: 3.18 )
Loading...