Security

The problem is,    1. Your web application’s domain name is www.foo.com   2. Your server IP is 123.123.123.123, and it sends emails to users from  support@foo.com    3. When a user  danni@gmail.com gets an email from it,  GMAIL may consider it is spam because it doesn’t know whether 123.123.123.123 really represents support@foo.com .   What you …

Add an SPF DNS record if you don’t want emails sent by your system defined as spam Read More »

An Https Certificate (a.k.a X509 certificate) is used to show others that you are really who you says you are. In a https-based c/s communication, including b/s communication, in most of the cases only the server side has to show a certificate. The client doesn’t need one, otherwise it will be very inconvenient for clients. …

What are the HTTPS Certificates in a C/S Communication and How are they verified? Read More »

By self-made https certificates, I mean one of the two kinds: 1. A self-signed certificate 2. A certificate issued by an unknown CA, for example, the certificate of https://www.12306.cn is by the CA of China’s Railway Department. Will there be security issues?  Yes, there is a big issue, but you can work around it in some cases. …

Will there be security issues of self-made https certificates ? Read More »

This is an incomplete list of things you should consider when you want to prevent your users being attacked by others. Note this is about protecting individual consumers with username/password pairs, rather than application clients such as third-party companies, who normally carry AppKey/AppSecret pairs.  Authentication There are several options.   Sending username/password as http request …

Prevent user attacking in HTTP RESTFul API calls Read More »

callback字符串中如果有JS源码，是可以进行注入攻击的。 服务端应该校验callback中是否有这种注入的东西，比如限定callback串只能由字母和数字组成

一个系统在处理另一个系统发来的请求时，如果遇到 "种类 = 可乐 & 口味 = 苦味" 这样的无意义参数组合，应该如何甄别出这是一个无效的请求？ 因为可乐不可能是苦味的，正常的系统不会发出这样的请求，这种请求只可能是别人伪造出来的。 最直接的甄别手段是在本系统里实现“可乐不可能是苦味”这种业务逻辑，但是本系统是一个基础应用，不应该让特殊的业务逻辑侵入。 另一种方案是让本系统通过RPC回调业务系统，校验是否“可乐，苦味”这种组合的有效性。但这会导致两个系统之间存在互调，对性能和发布都不利。 今天有个同事想出了一个简单的办法：发送端将参数组合起来加密，接收端解密文，如果解出来的东西不是一堆乱码，就可以认为这个组合是有效的。 即使中间人截获了报文，他也只能截获“可乐，甜味”，“可乐，酸甜味”这种有效的组合；如果中间人把这种组合发出来了，我们的基础系统也照样帮忙处理，没什么大不了的。 那为什么说中间人拼不出“可乐，苦味”这种无效组合的密文呢？ 因为中间人不知道具体的加密办法。 所以，通过加解密就可以保证参数组合是有效的。 当然，更简单的办法是用摘要，摘要算法如MD5是不可逆的加密算法，它的执行可以快一些；不过，MD5算法很容易被人猜到，你在MD5之前应该先往明文里掺点噪音数据，并让发送方和接收方使用相同的噪音数据。

今天有高人推荐了一款网站漏洞扫描器：Acunetix WVS 可以试试

摘自《Java加密与解密的技术》 CA三巨头： VeriSign, GeoTrust, Thawte  –都很贵，但会提供一些Trial Version 一个免费组织： www.cacert.org 中国各省均设有CA机构，如北京市数字证书认证中心

待完善…. KeyGenerator    — 用于生成Symmertric Key KeyPairGenerator   –用于生成Public/Private Key对 SecretKeyFactory — 把代表对称密钥的byte[] 变回 Key对象 KeyFactory  — 把代表非对称密钥的byte[] 变回 Key对象 KeyStore  —  in-memory collection of keys and certificates