> Android漏洞
主要Android漏洞主要包括App反编译重打包、组件劫持漏洞、密码泄露、第三方库漏洞、WebView漏洞、系统服务漏洞。
Android 内存溢出与内存泄漏的简单分析与解决- http://blog.csdn.net/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.csdn.net/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.csdn.net/carson_ho/article/details/64904635
Android中WebView的跨域漏洞分析和应用被克隆问题情景还原(免Root获取应用沙盒数据)- https://blog.csdn.net/jiangwei0910410003/article/details/79368602
最全面总结 Android WebView与 JS 的交互方式- http://blog.csdn.net/carson_ho/article/details/64904691
在WebView中如何让JS与Java安全地互相调用: http://blog.csdn.net/theone10211024/article/details/50439959
Android WebView的Js对象注入漏洞解决方案--http://blog.csdn.net/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.csdn.net/xyz_lmn/article/details/39399225
-- webView的安全漏洞
webView常见漏洞以及解决方法- http://blog.csdn.net/fulai00/article/details/52921779
Android4.2下 WebView的@addJavascriptInterface漏洞解决方案- http://blog.csdn.net/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.
2137
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
