Lets make something clear from the very start: JUST BECAUSE THERE IS https:// IN THE URL OF THE REMOTE SERVICE IT DOES NOT MEAN THE CONNECTION IS SECURE!
I am sorry for the tone of this post but i am enraged by how popular this issue is online. If you ask why i suggest a little experiment.
Steps to follow
- Change your host file settings to point something like www.somedomain.com to your development server
- Create a self signed certificate for this domain and setup a https virtual host to serve it on local IP or alias
- Put a test file on that URL
Please make sure you upgrade your PHP version to the latest version as soon as possible as it has a major security flaw which makes websites subject to the following DOS attack.
All you have to do is make PHP interpreter (older than 5.3.5 or 5.2.17) to convert string "2.2250738585072011e-308" to be casted into a numeric type. So if you have a form that accepts numbers which are then cast from strings into numeric values on server side you are probably affected.
Its not a new thing that passwords have to be kept safe. Unfortunately you cant protect every part of every system and you have to face the fact that some day your system may be hacked. Up till recently it would be safe enough to hash passwords using MD5 or SHA1 and put in some relatively safe place.
Unfortunately times have changed :-)
There are two similar security issues both taken care of by Suhosin patch and strict escaping/encoding rules. They both relate to injecting new lines into headers of network protocols. They are not very well known and i think its worth mentioning it.
HTTP response splitting is a web based attack where hacker manages to trick the server into injecting new lines into response headers along with arbitrary code. If you use GET/POST parameters in the headers like cookie or location, then someone could provide new lines with XSS attack.
Common example would be server redirecting to new location based on some variable (like url). To do it safely you should always encode/escape/cast strings before passing them into header PHP function.
An interesting little tip i read lately and thought its worth sharing. Apparently setting Apache to serve PHP files using AddHandler makes Apache to parse all files with ".php" substring in the file name (not only ending with php). The consequences can be very dangerous if you allow to upload files to the server and don't validate file names properly.
when you think of it at first it sounds like a great idea. All you have to do is set a global cookie for the main domain and based on that perform authentication. User will be able to go from subdomain to dubdomain and still remain authenticated.
Unfortunately there is second side to this story : )
To prevent XSS you will have to escape all the strings coming from GET/POST/COOKIES before you output them. You should escape things that come from other sources as well in case there is XSS attack string (for example dont include posts from RSS without escaping them properly).
When i say you should not generate CSS files dynamically i mean actually you should not put PHP variables into it.
From my experience it causes all sorts of problems from security to performance and caching. If you do not have to do it just don't. You cant still merge CSS files to have less requests per page and this is fine, but do not generate each file dynamically just join them and make sure its a safe way to do so.
Some websites validate some bits and pieces but fail in other cases assuming that user will not pass anything strange there.
French OS Con website is and example of that XSS security risk.
The simplest way to find XSS security hole is to look for forms and ajax calls that result in printing request parameters on the returned page.
Here is some simple example which took 5 mins to find. Just go to a website you want to verify and look for forms and action urls.
This example shows UCD website XSS vulnerability (possible in 2010).
This is a sample to show how to locate XSS attacks, do not try to hack sites this way
This post is my final look at the total of nearly 1200 pages long CISSP book.
In the end i think it was not a total waste of time as i really liked the physical security chapter and also chapter about cryptography was not that bad. Maybe it was not that bad of a refresh. But was it really worth it?
I would definetly not recommend it as i cant see who can really benefit from that book, its not senior and not junior, does not explain things well nor provide deep insights. Its just a too long poorly written book in my opinion.
Cross site scripts lead to a number of security issues. The most important to remember are:
- Session Hijacking - hacker steals user's session by getting his cookies and gets access to user's account
- Cross Site Forgery Request - hacker uses users account to perform operation that was not intended at all
I personally liked the chapter about physical security. I have not heard about some of the ideas described there and I must say its quite interesting. I am happy I kept on reading so far as this part was quite cool.
Authors describe what are the high level factors of physical security. They describe how different types of physical security elements work for example keys, magnetic cards, chip cards, as well as construction elements. Its even hard to describe but I really liked that chapter.
Synopsis: Its the first time i decided that i have to cut the book in parts to actually read it! Yes i took the biggest knife i had at home and cut the book in 5 parts.
Second part of the book is even a bigger disappointment than the first one. I read chapters 4 to 5 which amount to about 250 pages.
Chapter four is a very vague description of access control methods in the organization. It is a ton of fluff and very little real concrete information.