A majority of our products are security products and thus security must have a vital role in almost every development phase. As the book Web Security Testing Cookbook said: Security is a journey, not a destination. There is no such thing as ultimate secure. We can make things harder to break, but we can’t make things unbreakable. So on version 4.3, we retest the security like XSS, CSRF, Session Hijacking, SQL injection, Cookies,.. and fixed some bugs about security on Admin:

XSS attack

A serious and trivial persistent XSS vulnerability has been found. This indicates that there will be multiple places in the system where XSS is possible. In .NET most XSS attacks are prevented by enabling request validation in the web.config file: yet the application should itself be resistant for these types of attacks in case of explicit needs to process certain data. (Certain data is anything that looks like XML, such as “<a”: this need is plausible in many scenarios). We checked and fixed for the almost bugs related to XSS on Admin page, something like this:

CSRF attack

CSRF attacks are used by an attacker to make a system perform a function (funds Transfer, form submission etc.) via the target’s browser without knowledge of the user, at least until the unauthorized function has been committed. We create a Anti-XSRF token and add to ViewState of pages (anti-XSRF tokens are difference between pages and will be change when page reload). When pages are submitted, system will check Anti-XSRF token and reject invalid token.

Session Hijacking

The session token, a number that identifies a logged-in user, can be used from different locations and different browsers. When the token is obtained by an attacker, he can use the application as if he logged in himself. We have fix a bug about session hijacking by storing the IP of request machine to session cookie to prevent that.