lusiyu@ubuntu:~$ telnet xxx.edu.cn 110
Trying 202.116.xx.xx...
Connected to xxx.edu.cn.
Escape character is '^]'.
+OK Welcome to coremail Mail Pop3 Server (gdufss[f38963dfe10fa8653143525dfb027a3es])

可得知邮箱系统采用的是xxx mail，初步看了下，如果能找到一个XSS或者有意义的CSRF 入侵邮箱 考试满分便不再是梦想。
重点找找XSS，用小弟的账号登陆上去，发现可以添加图片标签及超链接标签，尝试源代码编辑，发送邮件给小弟账号自己。
内容为：

<a href=javascirpt:alert(1)>请点击</a>
<iframe/onload=alert(1)>

收到后查看内容
发现a标签 中javascript被过滤 iframe标签 onload属性被过滤
分别突破后得到0day两个
0×02 0day
0day1:
将

<script>alert(1);</script>

base64编码
得到

PHNjcmlwdD5hbGVydCgxKTs8L3NjcmlwdD4=

源代码编辑输入

<a href=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTs8L3NjcmlwdD4=>aa</a>

发送邮件，接收后点击，成功XSS。
0day2:
源代码编辑
插入

<iframe/onddd=alert(1)>

依旧发现onddd标签被过滤
这说明服务端过滤是基于黑名单的，就是on开头的属性都给PASS掉，估计因为很多可以执行JS的标签都是on开头，所以程序员这么想。
那就找一个不是以on开头的  又可以执行JS的iframe属性。
https://developer.mozilla.org/zh-CN/docs/HTML/HTML5
中找到一个srcdoc属性
发送邮件

<iframe srcdoc='<script>alert(1)</script>'>

登登 成功XSS収邮件者
自己工作忙 没时间继续测试了 跟小弟讲了下思路 恐吓下非法入侵他人邮箱坐牢等，最后他也没去做坏事v^v
0×03  思路总结
包括但不限于xxx mail这样的黑盒闭源 系统 挖掘XSS时，我们考虑这样挖掘：
1. 它支持什么标签
假如允许插入图片 超链接
那我们便知道<img src=> <a href>这些标签及属性是支持的，然后慢慢思考图片方法 比如url属性值可否设成javascript：vbsrcipt
2. 是否被过滤
如果被过滤 我们便测试下是黑名单还是白名单过滤。
比如上文的过滤on开头的属性，我们便可以用个on开头但不存在的属性 onddd来看看究竟是白名单还是黑名单过滤进而突破。
以上讲的是邮箱正文的XSS 其次还可以考虑附件名 在LINUX在附件名给成XSS语句测测？还有邮件签名档等等。
用户一切输入都是有害的，一切你能控制并在对方接收邮箱的时候展示的数据，都值得测测。
0X04  黑盒系统如何防御
该mail的官方应该用白名单来限制允许的标签，如只允许某些标签，至于属性应该写好正则，
比如超链接src属性用正则限制为正常URL形式。
0×05  附送一个新型的  XSS  防御方案
XSS的防御相信是很多程序员的痛，说容易些 过滤了尖括号等就行了，
但写代码或新人加入 总有疏忽的时候
毕竟业务第一 赶着上线时或许就没时间审计代码安全性了
那么 有没有很懒但很有用的方法来阻止XSS？
让程序员可以专注于业务开发？
这个方法针对的是反射型XSS（包括DOM XSS），或GET型导致的存储型XSS。
POST 导致的存储型XSS 我暂未想到便捷防御方法，如你有请联系我，欢迎赐教。
我们写一个JS

<script>
If(location.href.indexof(“<”)||location.href.indexof(“>”)||location.href.indexof(“%3c”)||location.href.indexof(“%3e”)||location.href.indexof(“javascript：”)||location.href.indexof(“vbscript:”)
{
window.stop ? window.stop() : document.execCommand("Stop");
</script>

每个页面都嵌入这个JS便可以有效防止反射型XSS（包括DOM XSS），或GET型导致的存储型XSS。如被绕过可再更改此JS 慢慢完善。具体根据业务情况而定。
这样 程序员便可以专注于业务 做安全的防御XSS 也轻松了一大半