网站升级至HTTP2
Tag http2, nginx, on by view 4353

HTTP2从提出到现在已经有一段时间了,不过目前使用该协议的网站并不多。不过著名如google, twitter, youtube他们都已经领先升级到了HTTP2协议。今天我也将自己的博客升级到了HTTP2。

重新编译安装最新的主线版本nginx 1.9.9

./configure --with-http_v2_module --with-http_ssl_module
make
make install

修改nginx配置文件

server {
    listen       443    ssl http2 fastopen=3 reuseport;
    server_name  duguying.net;

    ssl on;
    ssl_certificate /root/ssl/1_duguying.net_bundle.crt;
    ssl_certificate_key /root/ssl/2_duguying.net.key;

    location / {
        try_files /_not_exists_ @backend;
    }

    location @backend {
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host            $http_host;

        proxy_pass http://127.0.0.1:81;
    }
}

主要是添加 ssl http2 fastopen=3 reuseport

重启nginx服务。

接下来可以在浏览器上看到如下闪电图标(需要装插件 HTTP/2 and SPDY indicator)

http2.png


关于阿里云ESC上go语言项目编译6l: running gcc failed: Cannot allocate memory
Tag golang, 编译, 内存不够, swap, on by view 4322

前段时间将自己的阿里云服务器上的系统由centos 6.5换为了ubuntu 14,其他的硬件配置都没有发生改变,将服务器上的数据恢复并且重新安装了golang的编译环境后,发现使用go build编译稍微大一点的golang项目就会报错:

/usr/local/go/pkg/tool/linux_amd64/6l: running gcc failed: Cannot allocate memory

一直想不通为啥换了个系统就会报这个错,字面意思是gcc分配内存失败,应该是内存不够用,机器配置是1G内存,free -m 发现尚有400M的内存未使用,难道剩余400M的内存还不够go build命令编译代码使用?好吧,既然如此我就给它释放内存,kill掉众多的进程之后再进行go build编译,发现又可以编译了。之后发现偶尔能编译偶尔又不能编译,看样子确实是内存不够,可是为啥之前的centos系统上没有出现这种状况呢,一直不相信简单的“内存不够”就可以解释这一问题,因为之前的centos系统上是正常的,我甚至觉得可能是gcc版本的问题,猜测只有较高版本的gcc才会报这个错误。后来也曾在“golang天朝”论坛上发过帖子,并表达自己的猜测,认为不是内存不够这么简单,结果被别人鄙视不看英文……

不想花钱升级机器硬件,难道我只有装回centos?今天执行free -m偶然间注意到了swap的数值貌似一直是空的,我思考若是我添加swap交换空间是否能解决这一问题呢,毕竟swap其实就是用硬盘空间虚拟出的内存,一个内存的缓冲区。于是就给它加了个1G的文件作为swap,居然直接就可以用go build,再也不用担心gcc对我说Cannot allocate memory了。简单的记录一下添加文件作为swap的步骤:

  • 创建1个1GB的file

sudo dd if=/dev/zero of=/mnt/1GB.swap bs=1M count=1024
  • 格式化为Swap file

sudo mkswap /mnt/1GB.swap
  • 把swap file加入到系统中

sudo swapon /mnt/1GB.swap
  • 将swap永久添加
    在/ect/fstab中加入新的Swap分区

sudo gedit /etc/fstab
  • 在最后加入下列内容

/mnt/1GB.swap none swap sw 0 0

最后,free -m 命令可以看到swap的数据如下

             total       used       free     shared    buffers     cached
Mem:           992        903         88          0         57        188
-/+ buffers/cache:        656        335
Swap:         1023          0       1023

1G的内存交换区文件已经创建。


中文分词逆向最大匹配法项目实践
Tag 中文分词, 逆向最大匹配法, on by view 5744

最近在自己的项目中实现了中文分词,项目是pinyin-php,是一个用C语言完成的原生php扩展。 其主要作用是将中文汉字翻译成汉语拼音,其中用到中文分词主要是为了识别多音字,因为多音字一般是在特定词语环境中出现的。 因此系统需要识别汉字词语,也就是说要实现简单的分词,当然分词准确率越高的话多音字识别率也会越高。

pinyin-php中实现中文分词达到识别多音字的目的,这一想法在pinyin-php上一版本开发的时候就已经想到了。只是自己从来都没有实践过,而且据别人说,中文分词用C语言实现起来比较麻烦,反倒是脚本语言实现起来比较方便。我多方查阅资料后知道现有中文分词方法有如下几种

  1. 字符匹配

  2. 理解法

  3. 统计法

其中字符匹配是基于字典的字符串匹配,理解法是在字符串匹配的同时还对句子进行语义分析,统计法是基于大量的语料库来实现的。其中字符匹配法最为简单,后两者首先是算法比较复杂,是我目前尚未接触到的方法,其次他们均要基于大量的语料库进行数据分析,这对于我以及pinyin-php这个项目来说是不现实的。不过对于搜索引擎这种大型的系统来说是可以实现的。因此,我采用字符匹配法。字符匹配又有如下四种方式

  1. 正向最大匹配法(由左到右的方向);

  2. 逆向最大匹配法(由右到左的方向);

  3. 最少切分(使每一句中切出的词数最小);

  4. 双向最大匹配法(进行由左到右、由右到左两次扫描);

上面四种字符匹配方法要算『双向最大匹配法』最为准确,由于汉语的特性,『逆向最大匹配法』比『正向最大匹配法』要更精确。

pinyin-php采用的便是『逆向最大匹配法』。下面看个分词实例

硕士研究生产

正向最大匹配法的结果会是『硕士研究生 / 产』,而逆向最大匹配法利用逆向扫描,可得到正确的分词结果『硕士 / 研究 / 生产』。

项目中有一个字词库,其实是我自己实现的一个hashtable,系统初始化的时候从字词库中读取汉字和词语以及其对应的汉语拼音。

key,value
一,yī
丁,dīng
七,qī
万,wàn
丈,zhàng
三,sān
上,shàng
下,xià
……
阿Q,āQ
阿爸,ābà
阿鼻,ābí
阿呆,ādāi
阿弟,ādì
阿爹,ādiē
阿斗,ādǒu
阿飞,āfēi
阿哥,āgē
……

假设hashtable中的key的最大长度为10个汉字,那么有一段文字,我首先从尾部开始截取10个汉字,放入buffer{10}中然后在hashtable中查buffer[1~10],查到后就截取后续的10个汉字,未查到的话继续查字符串buffer[2~10],未查到继续查buffer[3~10],直到buffer[10],例如若是在buffer[4~10]的时候查到了,则将buffer[1~3]退回段落的原处。匹配到的词直接总hashtable中读取其拼音如此便翻译出来了,若是查找不到则直接保持为原来的字符不变。

分词就是将连续的字序列按照一定的规范重新组合成词序列的过程。

paragraph								buffer					segments
分词就是将连续的字序列按照一定的规范重新		组合成词序列的过程。
分词就是将连续的字序列按照一定的规范重		新组合成词序列的过程		/。
分词就是将连续的字序列按照一定的规			范重新组合成词序列的		/过程。
分词就是将连续的字序列按照一定的				规范重新组合成词序列		/的/过程。
分词就是将连续的字序列按照一				定的规范重新组合成词		/序列/的/过程。
分词就是将连续的字序						列按照一定的规范重新		/组/合成词/序列/的/过程。
分词就是将连续的							字序列按照一定的规范		/重新/组/合成词/序列/的/过程。

如果想了解我是如何编码实现的,欢迎参阅我的项目pinyin-php(https://github.com/duguying/pinyin-php)。


第一次发布项目到maven中央库
Tag maven, 中央库, 项目发布, on by view 5918

昨天晚上决定将java版的gojapi发布到maven中央库上,于是多方查阅资料后开始动手,期间遇到不少问题,结果弄到很晚都没弄成功,直到今天上午才成功的将其上传成功。现记录一下。

用到软件:
maven
gpg4win-vanilla-2.2.3.exe

参考文档:
http://my.oschina.net/huangyong/blog/226738

密钥对:

# 生成密钥对
gpg --gen-key
# 查看公钥
gpg --list-keys
# 将公钥发布到 PGP 密钥服务器
gpg --keyserver hkp://pool.sks-keyservers.net --send-keys 82DC852E

具体操作见参考文档。

接下来就是修改配置和上传了,先不配置上传试试

mvn clean deploy

mvn_401_error.png
401错误,未授权。接下来在mvn/conf/setting.xml中填入用户名和密码。

<servers>
    <server>
        <id>oss</id>
        <username>duguying</username>
        <password>xxxxxxxx</password>
    </server>
</servers>

再次上传,只要pom.xml中的distributionManagement>repository>id与上面的id是一致的,便可上传成功。在oss管理的页面(https://oss.sonatype.org)close之后发现close失败。如下图

mvn_oss_close_failed.png
按照上面提示,源码包缺失,文档包缺失,加密缺失,etc。这时应该在pom.xml的添加相关配置,下面是我完整的pom.xml文件

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>net.duguying.goj</groupId>
    <artifactId>gojapi</artifactId>
    <version>0.0.2</version>
    <packaging>jar</packaging>
	
	<name>goj judger client api</name>
    <url>https://github.com/gojudge/gojapi-java</url>
    <description>here is goj judger client api for java</description>
    <inceptionYear>2015</inceptionYear>

    <parent>
        <groupId>org.sonatype.oss</groupId>
        <artifactId>oss-parent</artifactId>
        <version>7</version>
    </parent>

    <licenses>
        <license>
            <name>MIT License</name>
            <url>http://opensource.org/licenses/MIT</url>
            <distribution>repo</distribution>
        </license>
    </licenses>

    <distributionManagement>
        <downloadUrl>https://oss.sonatype.org/content/groups/public</downloadUrl>
        <repository>
            <id>oss</id>
            <name>OSS Repository at sonatype</name>
            <url>https://oss.sonatype.org/service/local/staging/deploy/maven2</url>
        </repository>
        <snapshotRepository>
            <id>oss-sonatype-snapshots</id>
            <name>OSS Snapshot Repository at sonatype</name>
            <url>https://oss.sonatype.org/content/repositories/snapshots</url>
        </snapshotRepository>
    </distributionManagement>

    <scm>
        <connection>scm:git:git://github.com/gojudge/gojapi-java.git</connection>
        <developerConnection>scm:git:git@github.com:gojudge/gojapi-java.git</developerConnection>
        <url>https://github.com/gojudge/gojapi-java</url>
        <tag>HEAD</tag>
    </scm>

    <profiles>
        <profile>
            <id>release</id>
            <build>
                <plugins>
                    <!-- Source -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-source-plugin</artifactId>
                        <version>2.2.1</version>
                        <executions>
                            <execution>
                                <phase>package</phase>
                                <goals>
                                    <goal>jar-no-fork</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <!-- Javadoc -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <version>2.9.1</version>
                        <executions>
                            <execution>
                                <phase>package</phase>
                                <goals>
                                    <goal>jar</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <!-- GPG -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-gpg-plugin</artifactId>
                        <version>1.5</version>
                        <executions>
                            <execution>
                                <phase>verify</phase>
                                <goals>
                                    <goal>sign</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
            <distributionManagement>
                <snapshotRepository>
                    <id>oss</id>
                    <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
                </snapshotRepository>
                <repository>
                    <id>oss</id>
                    <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
                </repository>
            </distributionManagement>
        </profile>
    </profiles>

    <developers>
        <developer>
            <id>duguying</id>
            <name>duguying</name>
            <email>duguying2008@gmail.com</email>
        </developer>
    </developers>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpclient</artifactId>
            <version>4.4</version>
        </dependency>
		
		<dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpcore</artifactId>
            <version>4.4</version>
        </dependency>
		
		<dependency>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
            <version>1.2</version>
        </dependency>

        <dependency>
            <groupId>org.json</groupId>
            <artifactId>json</artifactId>
            <version>20131018</version>
        </dependency>
    </dependencies>

</project>

有了profile里面的内容便可以解决上面的问题,不过要想上传成功必须保证profiles>profile>distributionManagement>snapshotRepository>idprofiles>profile>distributionManagement>repository>id同样与setting.xml里面的server>id是一致的。否则就会报401错误。最后如下命令发布

mvn clean deploy -P release

这篇文章并没有详细的介绍如何将自己的java项目发布到maven中央库,而是描述了我发布的过程中遇到的问题,若想从头学习如何发布建议参考黄勇的博文 http://my.oschina.net/huangyong/blog/226738 。

maven 上传中可能遇到的一些问题

  1. gpg密钥丢失

    我换了一台电脑或者重装系统之后原来的 gpg 密钥已经不复存在了咋办。不用担心,你可以重新生成新的gpg密钥并上传,使用新的 gpg 密钥是完全没有问题的。

  2. gpg密钥上传后验证失败

    使用 --send-keys 上传了密钥之后,使用 --recv-keys 获取失败,或者偶尔成功偶尔失败,导致上传 maven 中央库后 close 操作后的 gpg 自动验证失败。此时你可以上传几个网络比较稳定的验证服务器作为备用服务器,例如 hkp://keyserver.ubuntu.com 。具体 maven 中央库支持哪些 pgp 服务器,可以从 gpg 验证报错信息中得出。


Goj开发过程中遇到gcc进程变为孤儿进程的问题
Tag Goj, 孤儿进程, deamon, Online Judge, on by view 3610

尽管现在已经放假,没有太多的心思放在开发上,但是Goj项目开发最近一直在缓慢的保持着。最近主要是处理judger与ojsite通信的问题,其过程中并没有遇到什么特殊的问题,TCP以及HTTP协议什么的都不成问题。但是在今天调试提交编译任务时却发现了一个有趣的事情,那就是gcc在特定情况下变成了deamon进程。

事情经过是这样的,但凡judger都必须经历#include "/dev/random"的考验,至於这是什么、为什么我也懒得解释,下面引用知乎上的一段话,感兴趣的自己看全文

小心编译期间的一些“高级功能”,比如 C 的 include 其实是有很多巧妙的用法,试试看在 Linux 下 #include "/dev/random" 或者 #include "/dev/tty" 之类的(这两个东西会把网络上不少二流 OJ 直接卡死……)。

而我的judger是这么解决这个问题的,创建一个线程监控编译子进程,超过一定时间kill。这样原本是没有太大的问题的,而且我也相信这也是一种正确的解决方案,但问题是我并不是直接用judger去调用gcc的,而是将gcc包装到了shell脚本,然后调用sh去执行脚本,这样做也是初期考虑到灵活性而决定的。于是judger的子进程是bash,而gcc是bash的子进程,编译任务阻塞后kill掉的是sh,于是gcc变为了孤儿进程,被init进程收养。

illeage_include.png

orphan.png

这倒不是什么难题,只要将进程改为能够kill掉gcc及其子进程便可解决,但是若是忽略这个问题将会是一个灾难,每一次#include "/dev/random"都将会让服务器产生deamon化的gcc进程,时间一久再多的内存都将会被gcc吃掉。



docker容器目录与主机目录同步
Tag docker, 目录, 同步, on by view 15309

docker能够将应用运行在容器中,它有许多优点,例如与主机环境隔离,应用部署方便等等。但是我现在希望能够将应用的数据存放到主机上,这样一来我就可以随意的创建和销毁docker容器,而不必担心应用数据的丢失了。

用过docker的人应当都知道docker可以进行端口映射,也就是将容器中的端口映射到主机的端口上,例如

docker run -d -p 1004:1004 -p 80:1005 duguying/judger

上例中就是将docker容器的1004端口映射到1004端口,将docker容器中的1005端口映射到80端口,其中-d表示以deamon进程的方式运行应用(即服务)。其实docker除了能够映射端口还能够映射目录,如下命令

docker run -d -p 1004:1004 -p 1005:1005 -v /var/goj/judger:/data duguying/judger

其中 -v /var/goj/judger:/data 便是将docker容器中的/data目录映射到主机的/var/goj/judger目录。但是有一点却需要注意,那就是当运行命令后docker初始化完成会将/var/goj/judger目录挂载到docker容器的/data目录,这样一来原docker容器/data目录将会消失,自然其中的内容也会丢失,因此,若是希望将配置文件放在挂载目录必须等到挂载完成后在docker容器中通过程序拷贝到挂载目录。若一切正常,那么/data目录下的内容会在主机的/var/goj/judger中,如此便可以实现将数据保存到主机目录。


sublime text 2插件开发,外部修改文件无法重新加载
Tag sublime, 插件, 开发, indent, python, on by view 6929

Indent是linux上很好的一款代码格式化工具,我在vim中很容易就配置其在文件保存时自动格式化代码,于是我打算开发一个sublime text 2插件(http://git.duguying.net/duguying/SublimeGnuIndent/src/master/Indent.py)调用外部命令indent(http://gnuwin32.sourceforge.net/packages/indent.htm),可是问题是外部修改的文件无法在有焦点的页面上自动更新,失去焦点然后又获取到焦点便可以更新。我希望请教是否有人能够点拨我一下如何解决这种问题。如下图

mistake_in_gunindent.gif

保存后,Indent确实格式化了代码文件,但是无法刷新,调用run_command('revert')也是无法将active状态下的编辑页面刷新的。但是在inactive状态下调用run_command('revert')却可以刷新。网上查找解决方案良久没发现有什么直接明了的方法。问题待解决。


xss攻击最终应对方案
Tag markdown, epiceditor, xss, 后端, 过滤, on by view 3696

今天终于解决了xss这个潜在的问题,编辑器使用的是Markdown编辑器EpicEditor,EpicEditor是一款Markdown编辑器,或者说是一款可以自己定制的编辑器。后台Markdown解析器用的是"github.com/russross/blackfriday",后台代码

func Markdown2HTML(content string) string {
	content = html.EscapeString(content)
	output := blackfriday.MarkdownCommon([]byte(content))
	return string(output)
}

直接将markdown语法的串解析为html语法的串,后台还设置了一个markdown解析api后面待用,api的controller代码如下

// parse markdown
type MarkdownController struct {
	controllers.BaseController
}

func (this *MarkdownController) Get() {
	this.Data["json"] = map[string]interface{}{
		"result": false,
		"msg":    "only post method support",
		"refer":  nil,
	}

	this.ServeJson()
}

func (this *MarkdownController) Post() {
	content := this.GetString("content")

	log.Blueln(content)
	rst := utils.Markdown2HTML(content)

	this.Data["json"] = map[string]interface{}{
		"result":  true,
		"msg":     "success",
		"preview": rst,
		"refer":   nil,
	}

	this.ServeJson()
}

前端将串传给后端,这个串期望是纯markdown的,因此如果其中夹杂着有html语法,html将会被转义,之后返回带有解析后的html串。

前端的EpicEditor默认是能够解析Markdown和兼容HTML的,甚至不过滤js(这个问题我已经向项目作者反馈过,他决定之后会给其添加选项以禁用js),由于我之前的文章提到css都会给用户机会造成页面混乱,而我所找到的过滤器只支持xss过滤,即只过滤js不过滤css,并且那个过滤器有一个依赖包在墙外,这将会是很蛋疼,所以决定使用markdown,是纯markdown。EpicEditor是兼容html的,因此不满足我的需求,于是我问EpicEditor的作者是否有禁用html的选项(传送),他告诉我EpicEditor不负责解析的,解析器可以自己定制,EpicEditor默认使用的解析器是markd解析器,然后给了我一个页面,其上有定制解析器的demo

var editor = new EpicEditor({
  parser: function (str) {
    var blacklist = ['foo', 'bar', 'baz'];
    return str.split(' ').map(function (word) {
      // If the word exists, replace with asterisks
      if (blacklist.indexOf(word) > -1) {
        return '****'
      }
      return word;
    }).join(' ');
  }
}).load();

自己重做一个解析器?看一下markd项目的代码有多少吧,重做工作量太大。仔细分析上面的代码发现parser是一个函数,它的作用是这样的,传入原串,返回解析后的串。这回我之前留的api起作用了,自己实现的parser函数如下

parser: function (str) {
	var rst = $.ajax({
		async: false,
		type: "post",
		url: "/api/markdown/preview",
		data: {"content": str},
		dataType:"json",

	}).responseText;
	var json = eval('('+rst+')')
	console.log(json);
	return json.preview;
},

是的,我将原数据传给服务器去解析,得到结果,这样还有一个好处就是保证了解析器的一致性,即最终结果与编辑器preview结果是一致的。当然这也是有一些缺点的,那就是给服务器增加了负担,不过我觉得这是值得的。最后附上编辑器工作的截图

epiceditor_back_end_anti_xss.png

问题能够得以解决应当感谢各个开源项目以及其作者的无私奉献,还有他们的热心答疑,取之于开源用之于开源,Goj也会是一个开源项目,愿早日完成。


css中不要在顶层使用*选择器
Tag css, 选择器, on by view 3445

今天遇到了一个比较坑的问题,使用Ace Editor却发现代码显示区与编辑器错位,表现是这样的,编辑器中一行代码结束了,但是移动光标却发现后面还有空白位,一开始我以为是空格之类的东西,于是删除最后一个空白位,然后最后一个字符就消失了,继续删字符继续消失,很明显是编辑区与显示区错位。

于是我怀疑是前面的css代码对此处的样式产生了影响,scss已经写了不少了,想直接查找是什么地方产生的影响是比较麻烦的,代码删减法,最后发现是全局样式文件中的一段代码导致的

*{
	font-family: $main-font-family;
	margin: 0;
	padding: 0;
}

其实之前对编辑器区域的审查元素发现编辑器几乎完全是由div元素构成,*表示匹配所有的元素,自然也包括了div元素,早就记不清是从哪儿学的这种写法,事实上这样写的目的是清除所有元素的默认margin和padding,开始的时候是觉得这么写也是无可厚非的,简洁有力,可是没想到有一些插件居然是基于浏览器默认的元素margin和padding来设计布局的,我在一开始的时候就将所有元素的margin及padding清零自然会影响到这些插件的样式。其实在用Ace Editor之前我用的是CodeMirror编辑器,但是CodeMirror却不受影响,估计是它指定了自己的margin和padding值,不受默认值影响。

现在越来越觉得使用*选择器是一件不靠谱的事情,*(通配符)的通用性太大了,匹配所有,是所有的元素。因此*使用的位置越靠顶层对全局的影响越是大,导致后期的故障或者冲突的可能性越大,尽管使用*选择器可能会节省一些代码,但是与导致的冲突相比是得不偿失的。*不能乱用,用在底层还好

.footer .footer-wraper .right .right-tag, .footer .footer-wraper .right * {
  ...
}

一般不要随意使用*,如果要使用*,建议在*下面不要再存在子元素,后或者下面的子元素不是很深并且样式在自己的控制之内。


XSS攻击应对方案
Tag XSS, 攻击, 跨站脚本攻击, on by view 6700

XSS(Cross Site Scripting),跨站脚本攻击,简单来说就是用户获取到了页面脚本执行的权限,够获取到JS脚本执行权限后能干的事情很多,比如盗取session id,从而实现登录帐号从而获取账户相关信息。

XSS攻击一般都是出现在有富文本提交的表单中,用户可以在提交的富文本中按以下各种方法插入JavaScript脚本:

<script>alert("hacked!");</script>
<img src="./" onerror="alert('hacked!');">
<a href="javascript:alert('hacked!')">foo</a>
<style>
div{
  background: url("javascript:alert('hacked!');");
}
</style>

以及其他的各种方法在页面执行Js脚本,当然黑客执行脚本的目的并不是为了弹窗装逼,而是读取当前用户的cookies,从而获取session id,达到非法登录用户账户的目的,简单来说就是不要密码盗号。

嵌入式web页面富文本编辑器很多,例如ueditor等,有人以为防范XSS攻击是这些编辑器的事情,事实上XSS攻击并不是这些编辑器能够阻止得了的,因为黑客是可以绕过编辑器提交表单的,所以防范XSS攻击的重点是后台字符串过滤,将非法的串过滤掉,当然还有另外一种办法,那就是使用第三方替代标签,如UBB标签(discuz中使用的就是这个)、Markdown等,不直接使用HTML系列的标签由其他标签转换为HTML,从而达到防止非法注入脚本的目的。

事实上富文本提交攻击防范远不止XSS这些,XSS主要是指Js脚本的攻击,可是有一种不致命却很糟糕的攻击却是被忽略了,那就是css脚本扰乱界面布局,事实上这应该算是纯粹的捣乱,可是却也能够严重的影响到页面的美观以及用户的正常使用,开源中国就曾经被大家用这种方法玩坏过。

<div style="display:block;position:fixed;width:100%;height:100%;background-color:red;"></div>

上面的代码便可以让整个网页变成红色。

因此,我个人认为html富文本的过滤不仅仅是简单的Js过滤,应当连css一起过滤掉。或者干脆使用第三方标签UBB等。