Security and Web sites: What lies behind your site?

When you can really be sure of having published a great site? When your casual  navigator is able to use it without reading instructions, tips and guides, in a natural way, focusing on content rather than on mechanical user interface. Simplicity is the first gift of the Web – but looks can be deceiving, and often not only deceiving the unsuspecting visitor, but also who produces the site, which underestimates the possible sources of security problems, as those who buy, which underestimates the size in terms of devices and people required to operate it.

You, do you really know your site?

The truth is that very often we know perfectly well, in an unconscious way, the twisted and insidious tower on which we support our union of art and technology, but we tend to ignore it focusing (often rightly, at least in certain moments of life of the project) on functional and aesthetic aspects of our site. After all we sell the customer visual compositions, evocative texts, user interfaces and contact forms!

We have already seen the reasons why we should push to consider the security problem in the development of our websites, no matter how complicated or who commissioned them (“Security and Web sites: what it means and why you should not underestimate on the internet?”), now let’s move on to examine in detail the functioning of these sites, to search for possible points of attack.

The view of the customer

Other side of the problem, very often the customer sees the product-web site acquired as a kind of simple “Power Point presentation” glorified, if not ” like the menu of a DVD“, something that for some strange reason we can’t always “put it on CDROM” and for reasons not really understood “does not work if I’m offline”, but that tends to accept it in trust, opportunity or advice, or because “everyone else is doing it” …

Sometimes we ourselves, in the first meeting and for valid reasons – let’s not scare him, or he won’t accept the estimate! – tend to inculcate the concept of simplicity. Too bad that, in reality, on the road that separates the browser from the web site there are hundreds or thousands of people involved with their problems of life, miles of cables of various types that run underground or under water and in harsh environments, servers and equipment with names and esoteric features dark and mysterious to most – very often, even to those who must manage the equipment …

And each of those peopleeach of those servers and equipment is a possible point of attack that can affect the operation of the web site: more than a glorified presentation! So, we need to know the steps that our website makes on the road from our beautiful collection of html and images on the server, to the visitor’s browser.  First of all, to armor our site on various sides, and then to explain to customers the reasons for our choices of development or, in the unfortunate event, the source and reasons of an attack.

The client sees us, and will always see, as responsible for what was delivered. It is reasonable, after all, it’s our product: what we have to make him understand, is that the operation and safety of what we gave him is partly ours, but also involves people and equipment out of our direct control: maybe we, as web programmers, know the people and equipment of the web farm and we can have security guarantees, but very rarely we can go further. No one can guarantee that the person managing an obscure and remote point of the network is selling the information extracted by sniffing the gateway which should monitor!

As always, remember that security on the web is mostly a matter of highest strength and effective recovery, not absolute inviolability: with the due time and the correct tools any wall can be eroded and door can be demolished, so our goal is to stretch that time to make the attack uninteresting or not accessible to most and give us time to prepare countermeasures, close loopholes or remove the treasure, before it’s stolen!

To each his own

Let’s analyze step by step how a website works:

  1. We designed an interface in HTML and CSS menus, scrollbars, buttons, text and so on. What we sold in our web project!
  2. The interface is handled through JavaScript, usually via jQuery style framework (to which I refer, but they are, however, concepts applicable to the vast majority of frameworks);
  3. The frameworks operate special visual effects, for the joy of the graphics department, but also communicate with the managed services on the server – the integration of live feeds to twitter or other social networks, database queries, calls to server REST, and the classic and very common “application form”, the form that accompanies us always – through AJAX calls executed by the browser;
  4. The browser sends requests received via AJAX, translating classical methods http: GET and POST applications classics, plus PUT and DELETE calls to REST server. To put it simply: the browser bundling our data and sends it to the server, indicating what to make of it;
  5. … our packets travel over the network, thousands of miles of wires and dozens of devices controlled and monitored by computers and human resources going through cups of coffee and lbs of chocolate …
  6. … and reach the server, where they are passed to our PHP application, which processes them, perhaps using a postgres or mysql database, and brings us back against another good packet, with the results of our demands …
  7. … that goes again through the network …
  8. … come to the browser, which responds to the framework …
  9. … and updates the interface, displays the feed, updates the table, changes the image, warns the user that the transaction was completed …
  10. … to the user, it will only be  a new text to read, a new image or a form sent: nothing complex!

We now review is the same list, in terms of security concerns and the maximum of paranoia:

  1. HTML that you see on the site could be affected: changes may have been introduced by malicious web farm directly, or modified in real time by malware installed on your PC by replacing the navigator links, changing images, etc.. Sometimes changes are subtle, a link, a text, sometimes things are absolutely no possibility of error: instead of the art gallery we find an illegal poker site (and, frequently, other kind of illegal web sites … ), or a graffiti style tag on the home page … Our site is the victim of an act called defacing;
  2. JavaScript can be disabled or altered in real time via console and development tools, the same ones that allow us to develop: the good old Firebug. And sometimes a web site can be compromised without even looking at the code, bypassing Javascript controls or by filling out a form field with special characters such as accent marks, or ampersands or html tags, or even SQL query: in this case, it is a code injection attack, which can lead quickly to defacing if not compromised data;
  3. frameworks do translate calls to servers bundling data in XML or JSON formats, in turn easily traceable, modifiable, and replicated through the unsuspecting Firebug console: another possible source of code injection;
  4. requests at this level are virtually identical to the classical requirements of any browser, and so can be intercepted by malware installed on your PC browser that can save them in a log and then send them to criminals, similar to key logging;
  5. … somewhere in between those dozens of devices, indistinguishable if considered on the basis of drinking coffee or eating chocolate, there could be someone dedicated or in charge to censor or just watch what you just sent, because maybe you’re not using any encryption …
  6. … transmission that still reaches the server, which may have been compromised as the PC browser, or controlled by criminals who are watching what you do as above, and could provide unexpected answers or would mislead the navigator …
  7. … Another possibility to be intercepted halfway, with an extra chance to alter the data that are provided to you …
  8. … Another possibility to be logged by malware on your PC before switching to the browser framework …
  9. … updating the interface, perhaps with data compromises …
  10. … that the user does not recognize as false, and which perhaps makes decisions. How, for example, proceed with payment by credit card …

(A word of advice … be paranoid in security matters, is just fine, but in the same way try to control the paranoia with a calculation of risks and benefits of what you do to protect yourself, protect each asset in proportion to its value, but don’t look for absolute protection, it is impossible or impractical, or with a cost greater than the value of what should be protected!)

It’s something to tear your hair out – and enough to write a book. Virtually every gear, every joint of our site is attacked, and this is the third law of security: everything is in enemy hands. Means every time we evaluate the security of our site, always consider what would happen if one or more of the parties involved were affected and in the hands of criminals, we assess the risks they face and where we can, we close flaws, where we cannot, we prepare an emergency plan and a good recovery strategy – and in any case never, never completely trust the security of parts and people that we do not control.

Good foundations

What does it mean for us web developers?

It means developing our sites considering the fact that the navigator could have a PC or browser infected or controlled, or the web server may be invaded and compromised from the outside and then destroyed, altered or monitored. The user that we think is, is actually someone else who has taken possession of his username and password for the web site (identity theft), or access his mailbox. That the user in front of our web site is not appreciating the beauty of our design and our special effects, but he’s watching our JavaScript, trying to figure out how to reach our databases or our php files for his use , consumption and abuse.

Discouraged? The bad news is that it’s too late to change job, and it doesn’t matter that no one told us when we choose it .. we are in now, and we need to understand how to change risks to virtues: knowledge about the problems when facing security on the web is always a selling point – if you present it with the humility of those who know they do not have to promise inviolable fortress, but can guarantee very solid walls.

Do not give up – and not ignore!

It would be nice to think only in combining colors, gradients and panels of the layout and to improve the fluidity of animation intro page – no, that’s a privilege to the art department, lucky them! Unfortunately, we do not, and it is important to clear it at the time of writing the first line of HTML, from foundations to roof. So:

  1. write code to prevent any type of code injection (how? We’ll talk plenty, soon);
  2. prepare the web site so that directories are not writable except in a very controlled way, so that our HTML is not trivially editable. These must be handled with extreme care, especially if they are accessible via a URL!
  3. Isolate the files that should not be directly accessed through URL (eg file inclusion, data files, sql, temporary files or uploading, etc) from those that do should be: this means so much to organize the site structure in advance and write the correct PHP code to Apache to impose rules that prevent or monitor access to certain directories (it speaks very well Tarchini Maurizio in “How to modify access to the files and folders?”);
  4. check the same way also ftp or ssh access – what would happen if the areas of my site via ftp were readable, perhaps with the accounts of other users of the same web farm?
  5. for any and all of our AJAX operations and any other communication with the server, including simply submit the form in the old style, we should always evaluate the effects if third parties could monitor transactions, read the contents. It’s sensitive data can be used for other purposes?
  6. if something went wrong, or parts of which we have no control were compromised and the web site hacked, can we, and if so what we need, rebuild the web site? Can we tell whether a site has been compromised in a very subtle way? Are our database backups useful?

The introduction ends here: from the next article we start with examples of code fragments (especially of what not to do!) and suggestions designed to solve or avoid problems we have discussed up to now – finally! A thought to do at the foot of these considerations: how important are safety issues and hidden complexity in the relationships with your clients?


Security and Web sites


What does it mean and why you should not underestimate the internet?

What lies behind your site?


  • Choose the theme or the plugin that most suits to your online business
  • Download and install it freely with few clicks
  • When you will be positive about your choice, enjoy the advanced features
Your Inspiration Themes >
[pdf]Scarica articolo in PDF[/pdf]
Tags: , , ,

The Author

Cristian is a freelance computer, specialized in the design and production of websites and, more generally, technology and Internet related mischief.

Author's web site | Other articles written by

Related Posts

You may be interested in the following articles:


Trackback e pingback

  1. Security and Web sites: Code Injection | Your Inspiration Web
    [...] What lies behind your site? [...]
  2. Security and web sites: how to find the causes of code injection attacks, validation techniques | Your Inspiration Web
    [...] What lies behind your site? [...]

Leave a Reply