The application environment is defined by the languages use to create the application. Just as every language has functionality that makes it perform certain tasks well; every language also has potential problems that make it a security risk.
Defining the Key HTML Issues
HTML5 has become extremely popular because it supports an incredibly broad range of platforms. The same application can work well on a user’s desktop, tablet, and smartphone without any special coding on the part of the developer. Often, libraries, APIs, and microservices provide content in a form that matches the host system automatically, without any developer intervention.
However, the flexibility that HTML5 provides can also be problematic. The following list describes some key security issues you experience when working with HTML5.
Code Injection: HTML5 provides a large number of ways in which a hacker could inject malicious code, including sources you might not usually consider suspicious, such as a YouTube video or streamed music.
Tainted Inputs: Unless you provide your own input checking, HTML5 lets any input the user wants to provide through. You may only need a numeric value, but the user could provide a script instead. Trying to check inputs thoroughly to ensure you really are getting what you requested is nearly impossible on the client side, so you need to ensure you have robust server-side checking as well.
Defining the Key CSS Issues
Applications rely heavily on CSS3 to create great looking presentations without hard coding the information for every device. Libraries of pre-existing CSS3 code makes it easy to create professional looking applications that a user can change to meet any need.
For example, a user may need a different presentation for a particular device or require the presentation use a specific format to meet a special need. The following list describes some key security issues you experience when working with CSS3.
Overwhelming the Design: A major reason that CSS3 code causes security issues is that the design is overwhelmed. The standards committee originally designed CSS to control the appearance of HTML elements, not to affect the presentation of an entire web page.
As a result, the designers never thought to include security for certain issues because CSS wasn’t supposed to work in those areas.
The problem is that the cascade part of CSS doesn’t allow CSS3 to know about anything other than its parent elements. As a result, a hacker can create a presentation that purports to do one thing, when it actually does another. Some libraries, such as jQuery, can actually help you overcome this issue.
Uploaded CSS: In some cases, an application designer will allow a user to upload a CSS file to achieve a particular application appearance or make it work better with a specific platform. However, the uploaded CSS can also contain code that makes it easier for a hacker to overwhelm any security you have in place or to hide dirty dealings from view. For example, a hacker could in
clude URLs in the CSS that redirect the application to unsecure servers.
CSS Shaders: A special use of CSS can present some extreme problems by allowing access to the user agent data and cross-domain data. Later articles on this blog will discuss this issue in greater detail, but you can get a quick overview of the topic at http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security. The big thing is that sometimes the act of rendering data on screen opens potential security holes you might not have considered initially.
Browser and Browser Plug-in Vulnerabilities: Many hackers rely on known browser and browser-plug in vulnerabilities to force an application to perform tasks that it wasn’t designed to do. For example, a user’s system could suddenly become a zombie transmitting virus code to other systems. The extent of what a hacker can do is limited by the vulnerabilities in question. In general, you want to ensure that you install any updates and that you remain aware of how vulnerabilities can affect your application’s operation.