在上篇文章中讲述了使用UIWebView拦截URL的方式来处理JS与OC交互。 由于UIWebView比较耗内存，性能上不太好，而苹果在iOS 8中推出了WKWebView。 同样的用WKWebView也可以拦截URL，做JS 与OC交互。关于WKWebView与UIWebView的对比，大家请自动百度或者google。
作者：matrix 被围观: 9,614 次 发布时间：2017-12-13 分类：零零星星 | 3 条评论 »
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
某次业务上线常规安全测试，有记录操作的功能，猜测存在存储型XSS漏洞，但由于存在长亭WAF被拦截。遂将之前总结的XSS绕过手段逐一测试了下。
步骤1：将需要调用的JS代码以.html格式放到src/main/assets文件夹里
事件就是用户或者浏览器执行的某种操作。我们常用的点击，滚动视口，鼠标滑动都是事件，为响应事件而调用的函数被称为事件处理程序，在js中事件处理程序的名字以 on 开头。
属性里可能存的是方法，也可能存的就是一个值（值有两个方法getter、setter）
在页面发现一处富文本编辑器，并且该内容提交后会显示在对应页面上，这里第一个想到的就是XSS了。
对于Android调用JS代码的方法有2种： 1. 通过WebView的loadUrl（） 2. 通过WebView的evaluateJavascript（）
//设置WebView缓存（当加载 html 页面时，WebView会在/data/data/包名目录下生成 database 与 cache 两个文件夹，请求的 URL记录保存在 WebViewCache.db，而 URL的内容是保存在 WebViewCache 文件夹下）
Android 和 H5 都是移动开发应用的非常广泛。市面上很多App都是使用Android开发的，但使用Android来开发一些比较复杂附属类，提示性的页面是得不偿失的。而H5具有开发速度快，更新不用依赖于App的更新，只需要服务端更新相应的页面即可，所以，App和H5页面相结合就显得尤为重要。而android和H5都不可能每次都是独立存在的，而是相互影响也相互的调用，获取信息等，例如，H5页面要获取App中的用户的基本信息，或者App端要操作H5页面等，下面来看看这两是怎么交互的
我们再补上IUserDao和UserDaoImpl的示例代码： IUserDao.java
之前介绍了移动端开发的相关技术，这一篇主要是从 Hybrid 开发的 JS Bridge 通信讲起。
iOS开发免不了要与UIWebView打交道，然后就要涉及到JS与原生OC交互，今天总结一下JS与原生OC交互的两种方式。
最近在逛github的时候看到一个bypass csp的挑战，也是我最近才知道的一个新思路，一般人bypass csp都是通过允许域下的某个漏洞构造文件绕过，但是其实往往没人注意到cdn的问题。
如果不想每个ajax都判断返回数据，然后进行未登录跳转的话，可以修改JQuery的默认设置(complete回调)：
弹窗包括：alert、confirm、prompt, 和url拦截类似都在回调方法中处理
字符串 controller 方法返回字符串可以指定逻辑视图名，通过视图解析器解析为物理视图地址 例： jsp
昨天我们将SpringMVC拦截后缀设置为*.form代表SpringMVC会拦截*.form结尾的后缀
近些年，移动端普及化越来越高，开发过程中选用 Native 还是 H5 一直是热门话题。Native 和 H5 都有着各自的优缺点，为了满足业务的需要，公司实际项目的开发过程中往往会融合两者进行 Hybrid 开发。Native 和 H5 分处两地，看起来无法联系，那么如何才能让双方协同实现功能呢？
一般情况下，一个项目的所有请求都会由一个统一的基础路径加上不同的接口路径和接口名组成，并且大部分接口都会有统一的请求或者响应处理，例如返回不同code值，要做响应处理，如果把所有接口都单独处理可谓是资源的极大浪费，因此想办法统一管理。在上一步中，已经新建了一个名为 service的文件夹，包含两个js文件：
经过45节的学习，很多同学已经达到了一个不错的水准，可以自主找到一些问题并修复和提出改进方法，我很欣慰。
官方介绍： 通过Hook XSS的常用函数,并监控DOM元素的创建,从而对整个页面的js行为进行监控。当发现页面中存在XSS攻击行为时,可根据预置的选项,进行放行,提醒用户选择,阻拦三种处理方式,同时预警中心会收到一次事件的告警,安全人员可根据告警进行应急响应处理。 在研究如何绕过一个系统之前，不急于直接读代码，先旁敲侧击看看这个系统大体都做了什么。 官方介绍中，在脚本加载前，需要执行一堆配置代码： <script type="text/javascript"> var hxj_config = {
这个就比较简单了，直接拖一个控件，再加载一下url，记得在AndroidManifest.xml中加一下权限
已经N年没挖SRC了，前几年曾有一段时间对XSS漏洞挖掘特别热衷，像反射型XSS、存储型XSS、DOM型XSS等挖得很上瘾，记下了很多笔记。遗憾的是多数平台都不愿意接收XSS漏洞，哪怕是存储型XSS漏洞给的评分都很低，因为XSS不能造成直接危害，利用起来有困难。所以当时花费了2天的时间，绕过各种防护及过滤，盲打到了一个SRC电商官网的后台。正好公众号文章写到现在，也缺少一篇讲解XSS漏洞的文章，这次就分享这个XSS拿权限的实战案例吧。
浏览器的同源策略，要同源说起。顾名思义，同源就是源头相同，即两个页面的协议、端口和域名都相同，任何一个不满足，都会导致跨域。
在前后端分离的时代，项目开发测试中我们常常因为前后端完成模块功能时间不一致而导致开发效率的降低，尤其是需要接口对接之时。鉴于此， MockJs应时而生，对此痛点予以重击。 本篇案例则属于一个简单的示范案例，在脱离后端（在没与后端联调前）怎么自己模拟数据来调试前端内容。
最近准备把之前用UIWebView实现的JS与原生相互调用功能，用WKWebView来替换。顺便搜索整理了一下JS 与OC 交互的方式，非常之多啊。目前我已知的JS 与 OC 交互的处理方式：
XSS／跨站脚本攻击，是一种代码注入网页攻击，攻击者可以将代码植入到其他用户都能访问到的页面（如论坛、留言板、贴吧等）中。
使用axios发起一个请求是比较简单的事情，但是axios没有进行封装复用，项目越来越大，会引起越来越多的代码冗余，让代码变得越来越难维护。所以我们在这里先对 axios 进行二次封装，使项目中各个组件能够复用请求，让代码变得更容易维护。
这是一个模仿真实xss挖洞的情景，在XSS Challenges练习过程中，我们需要用浏览器中的f12中搜索（），找出我们控制的代码所在的位置，然后思考那些个位置哪个或哪几个位置可以被注入我们想要的代码，然后结合上下文进行各种脑洞绕过。
UIWebView 在 iOS12 中已经被废弃，同时WKWebView在iOS8中已经出现。所以无特殊情况的话，我们一般应该也是用不到前者了！ UIWebView 相比于 WKWebView 的使用上会简单很多。
拦截器的作用在于，比如我们输入 xxx.com/admin 发起请求进入 网站后台或者其他后台页面。我们的拦截器会在 Controller 调用之前进行拦截，至于什么拦截，由我们来写。比如，判断用户是否登录(可以通过 session 判断)，如果没有登录，我们让它跳转到登录页面。
虽然找到了一处XSS，但是题目又说明：“我收到邮件后会先点开链接然后登录我的网站！”，而登录的域名是auth.hardxss.xhlj.wetolink.com，登录和打开链接是在不同的域名，并且需要盗取的信息在请求中而不是在cookie中。又注意到，直接访问https://auth.hardxss.xhlj.wetolink.com/，返回的页面源码的js中包含跨域操作：document.domain = "hardxss.xhlj.wetolink.com";，
周末肛了一下0ctf，发现自己依旧那么菜。一道题也没解出来，成功的再一次拖了队伍后退。 今天发现国外大佬们已经开始放wp了。于是自己学习一波，复现一下。 先吐槽一波 h4x0rs.club1 Flag is biography of the administrator. There are more than one way to get this flag. h4x0rs.club-https://h4x0rs.club/game/ backend_www got backup at /var/www/h
0x01开场白 这个议题呢，主要是教大家一个思路，而不是把现成准备好的代码放给大家。 可能在大家眼中WAF（Web应用防火墙）就是“不要脸”的代名词。如果没有他，我们的“世界”可能会更加美好。但是事与愿违。没有它，你让各大网站怎么活。但是呢，我是站在你们的这一边的，所以，今天我们就来谈谈如何绕过WAF吧。之所以叫做“杂谈”，是因为我在本次演讲里，会涉及到webkit、nginx&apache等。下面正式开始：） 0x02直视WAF： 作为第一节，我先为大家简单的说下一些绕过WAF的方法。 一：大小写转换法：
公司的一个web数据展示系统,本来是内网的,而且是一个单独的主机,不存在远程控制的问题,所以之前并没有考虑一些安全相关的测试.但是国调安全检查的需要添加这样子的一层防护措施,所以还是不得不添加一下. 仔细想一下,如果内网机被人意外连接网线,确实是会存在被入侵的可能,所以还是添加一下为好.
对于我这个菜鸟来说，我通过谷歌百度学习到很多前辈的资料，甚至每句话都是他的指导，我也很感激前辈的为我们铺设的道路，让我们更快的成长起来。我也乐于分享，可能有些知识点过于单调或者久远，请见谅。
WebChromeClient：当影响【浏览器】的事件到来时，就会通过WebChromeClient中的方法回调通知用法。
上一篇文章介绍了UIWebView 如何通过WebViewJavascriptBridge 来实现JS 与OC 的互相调用，这一篇来介绍一下WKWebView 又是如何通过WebViewJavascriptBridge 来实现JS 与OC 的互相调用的。WKWebView 下使用WebViewJavascriptBridge与UIWebView 大同小异。主要是示例化的类不一样，一些与webView 相关的API调用不一样罢了。
使用Spring MVC,配置DispatcherServlet是第一步。 DispatcherServlet是一个Servlet,所以可以配置多个DispatcherServlet。 DispatcherServlet是前置控制器，配置在web.xml文件中的。拦截匹配的请求，Servlet拦截匹配规则要自已定义，把拦截下来的请求，依据某某规则分发到目标Controller(我们写的Action)来处理。 注:“某某规则”是根据你使用了哪个HandlerMapping接口的实现类的不同而不同。 栗子：使用默认配置文件名
1、必须包含小数点 let regDis = /^(?=0\.[1-9]|[1-9]\.\d).{3}$|^([2-9])$/ 2、非必须包含小数点 let regDis = /^[0-9]{1}(
Fiddler充当第三者，主要是通过AutoResponder标签在客户端和服务端之间，Fiddler抓包，然后改包，最后发送。AutoResponder这个功能可以算的上是Fiddler最实用的功能，可以让我们修改服务器端返回的数据，例如：让返回都是HTTP404或者读取本地文件作为返回内容。宏哥将在实例中介绍利用AutoResponse功能。
根据需求需要将老项目中的 WebView 替换成 WKWebView，期间查阅了不少文档和资料，之前也发布了几篇 WKWebView 相关的优秀文章。
https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
作为前端，一直以来都知道HTTP劫持与XSS跨站脚本（Cross-site scripting）、CSRF跨站请求伪造（Cross-site request forgery）。但是一直都没有深入研究过，前些日子同事的分享会偶然提及，我也对这一块很感兴趣，便深入研究了一番。 最近用 JavaScript 写了一个组件，可以在前端层面防御部分 HTTP 劫持与 XSS。 当然，防御这些劫持最好的方法还是从后端入手，前端能做的实在太少。而且由于源码的暴露，攻击者很容易绕过我们的防御手段。但是这不代表我们去了解这块
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
