Methods for safety in web
The web is dangerous!Sadly enough, I have to admit that. Look at the news today- everybody does web and some individuals can even take over your pc and turn it into a bot. They have your pc and you won't even figure that while it sends millions of viagra offering emails to people out there. BOT networks are used to take down barriers of defence, deliver Denial-of-Service attacks or be part of a digital warfare somewhere beneath the surface. The horrible in that is the fact of you being part of this!
Nearly the same situation is given, if you start a web page. Every script, backend or feature is in the frontline taking attacks in order to take over the system and abuse it in your name.
We don't want that! So our mission is to secure our web application as far as possible.
Rule #01: All inputs can be malicousTake care of the inputs coming from those fields and scripts! Your Uniface (e.g. the USP, DSP or web service) backend has to be rock-solid and almost invulnerable to those things. This includes your code. Don't take $webinfo("input") or webget as a safety zone. Do test those values before using them. This prevents bad code to enter your set of data!
Rule #02: Consider when to use POST and GETBoth methods for transfering data (e.g. out of web forms) are fine, but doesn't fit every situation. Using GET puts every parameter to the URL (and so your history). Further every request typed in the adress line of your browser will start a GET. This is not good as it enables to get data without the (perhaps) needed fields in your application. Reduce those GET requests as far as possible. Don't use it to save code! A basic usage could be:
- use GET for : templates, small request, basic page load
- use POST for : saving data to the backend or doing other stuff people shouldn't be able to!
In general you should use POST while using the form tag. Let me show you how to take care of those requests in Uniface with just some simple lines of code ...
Rule #03: Manage users with sessionsNobody should be able to alter your data whithout being registered in the system. This causes trouble and disables you to stop those changes. If a user messes around in your system, then just wipe him out or disable his account! This makes life easier and you happier.
Rule #04: add checksums to data and validate itIn Uniface you use retrieve/reconnect to get back to your occurences. Internally Uniface compares the occurences with $occcrc(entity). If possible do the same! This assures you to have valid data in your occurrence. Depending on how much you took care on your data retrieval in web, Uniface manages this alone. But I know about other scenarious where this is pretty usefull.
I guess, that's it for the moment. If you have some good advice just let me know.
Your application should always be REST-full. Only POST and PUT will have a body. The other three GET and DELETE onle have a query-string. Obey always the rules as described in: http://www.w3.org/Protocols/rfc2616/rfc2616.html. Cpwr gives one other solution.: the application shell. For web application you can define your own application shell to handle all authentication control. The GetState trigger is for the authorization control.