Categories
- BLOG -

Understanding Information Security in Web Applications

Checkout our own PHP framework designed for secure web application: Dotz Framework.

As a manager of a technical project it’s good to know fundamentals of information security and good security practices even if you’re not one of the developers.

Even good developers often find themselves unaware of basic security protocols to follow when developing web applications as they typically have their hands full with other development concerns.

However; managers of varying degrees involved with Information System projects should be particularly concerned that someone is looking after security for their web application projects. As this could hurt your organization’s bottom line.

Two Frontiers of Threats…

As a non-specialist in Information Security (my experience lies in architecture and scalability); I will take a deep breath and give my two cents on how I view security on the web…

There are two broad areas of concern when it comes to web applications’ security in the application layer:

  1. Inputs/OutPuts: Any point of information input/output for a web application is a potential concern for security.
  2. Identity Theft: There are a handful of ways a malicious user, software or web application can steal an un-suspecting user’s identity.

Let’s try to discuss these two types of threats in further detail. I must once again mention that these security concerns apply to the application layer specifically, as defined in this post; and not all layers of the web application infrastructure are covered.

Inputs and Outputs
  • SQL-Injection attack: When information is being inputed by a user they could attack the app by injecting malicious database-queries that cause data loss, corruption or leaks.For this reason all data being received from a user must be escaped/cleansed before it touches the database layer. Common PHP extensions for MySQL have escaping functions that should be used before any input is used in a database query. Always check for data-escaping of all inputs!
  • Inputs can also contain malicious code that gets executed on the server side or client side causing any number of potential un-wanted outcomes.Therefore, any input that is coming into the app should be checked before it is outputted on any user’s screen; and it should be checked to ideally NEVER contain executable server-side code. Inputs should be kept in check to ensure no attacks on the server-side or client-side can happen.
  • All data coming out from the database as output to a user’s browser should be filtered for malicious javascript code if that database input was originally submitted by (some-other) user. This is usually one check most systems are inconsistent in maintaining, as it’s hard to keep track of such data flows.
Identity Theft

There are two types of identity thefts that I’m aware of:

  • Cross-site Request Forgery (CSRF) attacks: as an example, when I login to my bank’s online client portal using my browser; and carry out my banking activity; and while the page is open I shoot up another tab in my browser and head over to some malicious website that opportunely takes advantage of my session from the bank site to carry out malicious transactions on my behalf.Now you might sit their scratching your head and say, “that sounds a bit far out!” Apparently it’s happened; so as a concerned steak-holder in your web application, it’s better to develop a strategy for CSRFs.
  • Cross-site Scripting (XSS) attacks occur with malicious inputs from one user that get displayed on another user’s browser (as described above in the Input/Outputs section); with the intent of some how attaining that second user’s private data/identity.So – for example – some Javascript code that ends up displaying a form to the victim-user, asking for them to enter their credit card number which gets sent to the XSS attacker; or any number of other malicious scripts that can get passed around by your web app because you did not sanitize all user inputs and outputs!XSS attacks are linked to the security concerns mentioned above in the input/output section.

Conclusion

Check your app’s inputs and outputs and deliberate a strategy to overcome CFRS/XSS attacks as best as you can in your web applications for better days ahead!