Customized Best Practices from HackVidhi

A web application developer must always follow a set of best practices to ensure that his/her web application is secure. If followed properly, the best practices can guarantee a good fight against the malicious content and attacks. Yet, most of the application lack these practices and are vulnerable to web threats. For few, the practices were not followed due to the lack of time, few others had the functionality limitation while others had just a negligent attitude towards the security. The reason could be anything, but if exploited to the core, the consequences could be damaging.
The basic best practices you must follow in your web application -

• Parameterized Queries: If your application deals with SQL, always write parameterized queries or prepared statements. This can save your application from SQL injection. In other terms, it won't allow an attacker to change the dynamic queries.
• Save sensitive data: If your application stores sensitive files such as customer information, always store such files outside of the webroot. And if your application has limitation which does not allow you to do so, explicitly make sure to secure them using encryption.
• Check for buffer-overflow:  Always make sure that there is enough buffer so that the flow of your application could not get choked by any bad intent. An efficient memory management should always be a  must-consideration.
• Proper error-handling: One of the common strategy used by hackers is to make your web application fail and get the information out of the error thrown on the browser. So make sure that your web application has a proper error-handling mechanism implemented in it which will prevent leakage of any core information even if it fails.

This list is not complete yet. We can add few more points here and the list would still be incomplete. 

At HackVidhi, we help you understand these practices better. Along with all of our security testing services, you can exploit free consultation to make your website or web application secure and  we will also provide you a set of customized best practices tailor-made for your application. We believe in not only providing our clients the best services but also enriching their knowledge in the area of web security.

- Richa

99% of Top Indian Websites can be 'UI Redressed'!!

Today I performed some analysis on current usage trend of X-FRAME-OPTIONS in top 500 websites of India (I used the sites listed here); this analysis came out with interesting statistics;

• ·         92% of the top Indian websites don’t use X-FRAME-OPTIONS at all.
• ·         Here the worth noticing point is that most of the 18% sites which use X-FRAME-OPTIONS are not of Indian origin, Alexa doesn't take into account the origin factor in enlisting top sites for a country; it sorts the websites based on number of hits.
• ·         This eventually leads to the fact that only 1% Indian sites are actually using X-FRAME-OPTIONS!!
• ·         Out of rest 99% top web sites (of Indian origin), half of them are relying on different frame-busting scripts to avoid this threat; and I will explain later that why scripts are not full proof, as there exists at least one way to break each of these scripts.
• ·         Rest half of those 99% are not using any techniques to avoid UI Redressing attacks!!
• To my surprise I even saw one web site using some strange value for this X-FRAME-OPTIONS header - ‘GOFORIT’, this too in a relatively popular telecom website.

This makes me very curious about the security practices that Indian websites are following. Web security if one of those areas which should not be overlooked; it should be given the amount of attention it deserves.

<Here is A brief overview of UI Redressing Attack; I am not going deep as a lot of useful material is available on the internet for UI Redressing Attack.>

UI Redressing attack in its basic form can be visualized as –

So the attack lies in having user see a different interface but actually interact with an altogether different interface. For instance in the example above the user will think that he is claiming his gift but actually he might be transferring his funds to some other bank account (of course if his account is open in some other tab). The most common vehicle of delivering this threat is to use iframe. Attacker embeds the webpage he wants to attack in his iframe and makes it invisible while making his own content visible; when a genuine user performs some actions on attacker’s page, the user is actually performing actions on background page as well.

There exist various advance mechanisms using which an attacker can manipulate user’s input on his page and force to send selective input on the hidden page. I will be writing about these advance exploitation mechanisms in a different article probably.

Possible Impacts-

Attacker can cause user to perform certain actions which he will not perform consciously; example of such actions include transferring funds from his online bank account, cancelling orders that he placed on some e commerce site or changing delivery address corresponding to those orders etc; the list can be endless.

Safety measure that websites are using to avoid this attack: FRAME-BUSTING-

Most of the websites today are using frame-busting techniques to overcome this threat; frame-busting as the name indicates involves detecting whether the page is being loaded in a iframe and then bust this frame to come out!! Different scripts are being used to achieve frame-busting in different sites.

How FRAME-BUSTING techniques\scripts can be circumvented-

There is a paper published by couple of Stanford University Students which talks about how the frame-busting scripts can be broken; this paper explains that eventually a way exists to break almost each of the scripts that websites are using currently to implement frame- busting. 

Moving Towards HTTP Header: X-Frame-Options-

This is better solution in comparison to frame-busting scripts. This header restricts the possibility of being the page framed; this header can have three possible values;

DENY-
This option means the page can never be framed by any page, even not by a page with the same origin.

SAMEORIGIN -
This option means the page can be framed, but only by another page with the same origin.

Allow-From-
This option means the page can be framed, but only by the specified origin.

-Archana