Android漏洞，WebView漏洞，Web漏洞与Web安全

最新推荐文章于 2025-02-06 11:52:26 发布

desaco

最新推荐文章于 2025-02-06 11:52:26 发布

阅读量2.7k

点赞数

分类专栏：安全/(反)混淆浏览器Browser/搜索引擎

安全/(反)混淆同时被 2 个专栏收录

18 篇文章

订阅专栏

浏览器Browser/搜索引擎

16 篇文章

订阅专栏

本文详细介绍了Android WebView常见的安全漏洞，如JS对象注入、跨域漏洞等，并提供了具体的解决方法。同时，针对WebView引起的内存泄漏问题给出了多种实用的避免和解决策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

> Android漏洞
主要Android漏洞主要包括App反编译重打包、组件劫持漏洞、密码泄露、第三方库漏洞、WebView漏洞、系统服务漏洞。
Android 内存溢出与内存泄漏的简单分析与解决- http://blog.youkuaiyun.com/u014674558/article/details/62234008?ref=myread
-- static引用泄露，将静态的改为软引用或非静态的引用

> Web漏洞，Web安全
WEB安全：XSS漏洞与SQL注入漏洞介绍及解决方案: http://www.cnblogs.com/ITtangtang/p/3982297.html
Web安全测试之XSS:http://www.cnblogs.com/TankXiao/archive/2012/03/21/2337194.html
WEB安全实战（五）XSS 攻击的另外一种解决方案（推荐）: http://blog.youkuaiyun.com/happylee6688/article/details/41314351
预防WEB页面XSS漏洞的简单方式: http://xiemingmei.iteye.com/blog/2105826

XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。跨站脚本攻击的分类主要有：存储型XSS、反射型XSS、DOM型XSS。跨站脚本攻击的危害：窃取cookie、放蠕虫、网站钓鱼 ...
《深掘XSS漏洞场景之XSS Rootkit》，“ xss本质是在于执行脚本[javascript/html等]，而一个javascript就足够让你黑遍这个世界！”.XSS并不仅仅是弹个框框或者一个死循环的alert那么简单。
-- 思考：拒绝服务攻击漏洞、跨站请求伪造(CSRF)、开放重定向漏洞等.

> Android WebView漏洞
从Web App，到PhoneGap，Titanium，MonoTouch，再到Native App.
Android WebView Memory Leak WebView内存泄漏- https://my.oschina.net/zhibuji/blog/100580
Android：你不知道的 WebView 使用漏洞- http://blog.youkuaiyun.com/carson_ho/article/details/64904635
Android中WebView的跨域漏洞分析和应用被克隆问题情景还原(免Root获取应用沙盒数据)- https://blog.youkuaiyun.com/jiangwei0910410003/article/details/79368602
最全面总结 Android WebView与 JS 的交互方式- http://blog.youkuaiyun.com/carson_ho/article/details/64904691
在WebView中如何让JS与Java安全地互相调用: http://blog.youkuaiyun.com/theone10211024/article/details/50439959
Android WebView的Js对象注入漏洞解决方案--http://blog.youkuaiyun.com/leehong2005/article/details/11808557/
Android WebView漏洞(转)-- http://www.cnblogs.com/goodhacker/p/3343837.html
Android webview新漏洞，可导致同WiFi网络可窃取SD卡内容-- http://wmcxy.iteye.com/blog/1948828
Android Webview UXSS 漏洞攻防-- http://riusksk.blogbus.com/logs/271896142.html
Android WebView 在开发过程中有哪些坑？ http://www.zhihu.com/question/31316646
在WebView中如何让JS与Java安全地互相调用- http://blog.youkuaiyun.com/xyz_lmn/article/details/39399225

-- webView的安全漏洞
webView常见漏洞以及解决方法- http://blog.youkuaiyun.com/fulai00/article/details/52921779
Android4.2下 WebView的@addJavascriptInterface漏洞解决方案- http://blog.youkuaiyun.com/zhouyongyang621/article/details/47000041
JS与WebView交互存在的一些问题- http://www.jianshu.com/p/93cea79a2443

在Android系统4.3.1~3.0版本,系统webview默认添加了searchBoxJavaBridge_接口,如果未移除该接口可能导致低版本Android系统远程命令执行漏洞；
修复建议：判断系统版本，显式调用removeJavascriptInterface方法移除searchBoxJavaBridge_接口；
// 在Android系统4.3.1~3.0版本,系统webview默认添加了searchBoxJavaBridge_接口,如果未移除该接口可能导致低版本Android系统远程命令执行漏洞
//如果真的需要没有这些漏洞的话，你可以尝试用腾讯的X5内核，和WebView用法一样。
removeJavascriptInterface("searchBoxJavaBridge_");
removeJavascriptInterface("accessibility") ;
removeJavascriptInterface("accessibilityTraversal");

if(Build.VERSION.SDK_INT == 18){
mWebView.removeJavascriptInterface("searchBoxJavaBridge_");
}
if (Build.VERSION.SDK_INT >= 11 && Build.VERSION.SDK_INT < 17) {
try {
webView.removeJavascriptInterface("searchBoxJavaBridge_");
webView.removeJavascriptInterface("accessibility");
webView.removeJavascriptInterface("accessibilityTraversal");
} catch (Throwable tr) {
tr.printStackTrace();
}
}

-- WebView CPU高负荷问题，在Android中采用网页的方式进行视频数据展现和播放时，发现CPU总是居高不下，在70%—80%之间徘徊，所以通过以下方式来查看和定位：
1、adb shell: top -m 5 -s cpu 和 top -m 10 -t
2、DDMS：Heap、Threads、Allocation Tracker、System Information
均未发现有价值信息，再看看WebViewCoreThread、MediaServer占用的CPU、内存也并不高，所以进行如下隔离测试：
a、单独的APK视频播放正常;
b、单独的HTML+视频播放正常;
c、载入视频页面+播放视频异常;
d、载入视频页面+不播放视频异常;

看来都没有关系，最后发现光标从滚动字幕上离开时，CPU逐渐恢复正常……，总结一下：单独用marquee本身，影响不是很大，主要在于页面如果有其他的脚本事务，如光标系统、视频播放等往往会因为滚动效果的叠加CPU占用情况会放大。还有个更为重要的一点，应该算是Android的一个BUG：如果manifest中不配置android:targetSdkVersion="15" 类的属性，一切正常如果配置了则CPU提升很明显。除此之外：
1、在WebView中尽可能不要使用GIFs、Marquee、Blink等动画和渲染效果，Marquee不要用，有四个以上页面会好卡，如果的确需要使用可以用程序写，JQUERY中应该有现成的。
2、Gif可以用但不要太多，页面加载状态的控制可以用一下，其他的不要考虑，当然GIF不显示出来，也不会占用CPU。

-- 有人说，一旦在你的xml布局中引用了webview甚至没有使用过，都会阻碍重新进入Application之后对内存的gc。包括使用webview有时一会引发OOM，几经周折在网上看到各种解决办法，在这里跟大家分享一下。但是到目前为止还没有找到根本的解决办法，网上也有说是sdk的bug。但是不管怎么样，我们还是需要使用的。
要使用WebView不造成内存泄漏，首先应该做的就是不能在xml中定义webview节点，而是在需要的时候动态生成。即：可以在使用WebView的地方放置一个LinearLayout类似ViewGroup的节点，然后在要使用WebView的时候，动态生成即：
    WebView mWebView = new WebView(getApplicationgContext());
    LinearLayout mll = findViewById(R.id.xxx);
    mll.addView(mWebView);

然后一定要在onDestroy()方法中显式的调用
    protected void onDestroy() {
    super.onDestroy();
    mWebView.removeAllViews();
    mWebView.destroy()
    }

注意：new WebView(getApplicationgContext()) ;必须传入ApplicationContext如果传入Activity的Context的话，对内存的引用会一直被保持着。有人用这个方法解决了当Activity被消除后依然保持引用的问题。但是你会发现，如果你需要在WebView中打开链接或者你打开的页面带有flash，获得你的WebView想弹出一个dialog，都会导致从ApplicationContext到ActivityContext的强制类型转换错误，从而导致你应用崩溃。这是因为在加载flash的时候，系统会首先把你的WebView作为父控件，然后在该控件上绘制flash，他想找一个Activity的Context来绘制他，但是你传入的是ApplicationContext。后果，你可以晓得了哈。

于是大牛们就Activity销毁后还保持引用这个问题，提供了另一种解决办法：既然你不能给我删除引用，那么我就自己来吧。于是下面的这种方法诞生了：（作者说这个方法是依赖android.webkit implementation有可能在最近的版本中失败）
    public void setConfigCallback(WindowManager windowManager) {
    try {
    Field field = WebView.class.getDeclaredField("mWebViewCore");
    field = field.getType().getDeclaredField("mBrowserFrame");
    field = field.getType().getDeclaredField("sConfigCallback");
    field.setAccessible(true);
    Object configCallback = field.get(null);

    if (null == configCallback) {
    return;
    }

    field = field.getType().getDeclaredField("mWindowManager");
    field.setAccessible(true);
    field.set(configCallback, windowManager);
    } catch(Exception e) {
    }
    }
然后在Activity中调用上面的方法：
    public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setConfigCallback((WindowManager)getApplicationContext().getSystemService(Context.WINDOW_SERVICE));
    }

    public void onDestroy() {
    setConfigCallback(null);
    super.onDestroy();
    }
该反射方法在我的实验中（2.3.6）确实有些用处，在应用内存占用到70M左右的时候会明显释放到50M或者60M然后的释放就有些缓慢，其实就是看不出来了。之前在没使用该方法的时候可能达到120M。

只要你仔细看好下面一句话：那就是为加载WebView的界面开启新进程，在该页面退出之后关闭这个进程。
但是在这个其中，杀死自己进程的时候又遇到了问题，网上介绍的各种方法都不好使，
killBackgroundProcesses(getPackageName());各种不好用，最后使用System.exit(0);直接退出虚拟机（Android为每一个进程创建一个虚拟机的）。这个肯定不用纠结了，一旦退出，内存里面释放。听涛哥说QQ也是这么做。
这个泄漏出现在external/webkit/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp.中。
--- a/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp
+++ b/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp
@@ -63,10 +63,10 @@ public:
JNIEnv* env = JSC::Bindings::getJNIEnv();
// Initialize our read buffer to the capacity of out.
if (!m_buffer) {
- m_buffer = env->NewByteArray(out->capacity());
- m_buffer = (jbyteArray) env->NewGlobalRef(m_buffer);
+ ScopedLocalRef<jbyteArray> buffer_local(env, env->NewByteArray(out->capacity()));
+ m_buffer = static_cast<jbyteArray>(env->NewGlobalRef(buffer_local.get()));
}
int size = (int) env->CallIntMethod(m_inputStream, m_read, m_buffer);
if (checkException(env) || size < 0)
return;
// Copy from m_buffer to out.

还有一个问题要说的，也是在WebView使用的时候出现的问题：WebView中包含一个ZoomButtonsController，当使用web.getSettings().setBuiltInZoomControls(true);启用该设置后，用户一旦触摸屏幕，就会出现缩放控制图标。这个图标过上几秒会自动消失，但在3.0系统以上，如果图标自动消失前退出当前Activity的话，就会发生ZoomButton找不到依附的Window而造成程序崩溃，解决办法很简单就是在Activity的ondestory方法中调用web.setVisibility(View.GONE);方法，手动将其隐藏，就不会崩溃了。在3.0一下系统上不会出现该崩溃问题，真是各种崩溃，防不胜防啊！

-- 最后还有内存泄漏的一些个建议：
In summary, to avoid context-related memory leaks, remember the following:
Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself)
Try using the context-application instead of a context-activity
Avoid non-static inner classes in an activity if you don’t control their life cycle, use a static inner class and make a weak reference to the activity inside。
And remember that a garbage collector is not an insurance against memory leaks. Last but not least, we try to make such leaks harder to make happen whenever we can.