Hide Apache and PHP Version and Signatures in Ubuntu Linux

Apache Security

By default, your Apache web server (and PHP if it is installed) will indicate to clients the exact version of the Apache software which is running. This version information can be seen in the HTTP response header.

At times, such behaviour is undesirable as some administrators think that this will make their server more vulnerable to attacks since an attacker will immediately know what software versions are running and may then easily gather any available exploits. The simple fact is, even if your server software is masked, and attacker can try to determine the versions using other means, or they can just try to attack it using all the exploits they have.

Regardless of whatever your intention is, turning off these signatures will add an additional level of complexity (albeit minimal) to a potential attacker.

The tutorial below explains.

How to disable Apache signature

Open the relevant apache2.conf config file:

nano /etc/apache2/apache2.conf

At the end of the file, or at some other sensible location, add the following lines:

ServerTokens Prod
ServerSignature off

Restart your server for the new changes to take effect:

/etc/init.d/apache2 restart

How to disable PHP signature

Open the relevant php.ini config file:

nano /etc/php5/apache2/php.ini

Find the line that says:

expose_php = On

And change it to:

expose_php = Off

Finally restart your server again for the new changes to take effect:

/etc/init.d/apache2 restart

Now your server is a little bit more secure from attackers since it will only indicate that it is an Apache server with no clues as to the version number of the modules which are installed.

Note: Disabling the “Server: Apache” line in the HTTP response header altogether cannot be readily done using configurations (if at all), and will usually have to be done by recompiling the web server binaries. If you are running such a critical application that warrants such extreme measures, this task is left up to you. The bottom line is that if your software is kept up to date, it shouldn’t matter if an attacker knows what type of web server you are running.

Secure Apache from Clickjacking with X-FRAME-OPTIONS

Apache Security

Clickjacking is well known web application vulnerabilities. For example, it was used as an attack on Twitter. To defense Clickjacking attack on your Apache web server, you can use X-FRAME-OPTIONS to avoid your website being hacked from Clickjacking.

The X-Frame-Options in HTTP response header can be used to indicate whether or not a browser should be allowed to open a page in frame or iframe. This will prevent site content embedded into other sites. Did you ever tried embedding Google.com in your website as frame? You can’t because it’s protected and you can protect your’s too.

There are three settings for X-Frame-Options:

1. SAMEORIGIN: This setting will allow page to be displayed in frame on the same origin as the page itself.
2. DENY: This setting will prevent a page displaying in a frame or iframe.
3. ALLOW-FROM uri: This setting will allow page to be displayed only on the specified origin.

How to implement in Apache, IBM HTTP Server?

Add following line in Apache Web Server’s httpd.conf file

Header always append X-Frame-Options SAMEORIGIN

Restart Apache Web Server

Note: This implementation is applicable in IBM HTTP Server as well. You can add above Header parameter in httpd.conf of your IBM HTTP Server instance.

How to implement in shared web hosting?

If your website is hosted on shared web hosting then you won’t have permission to modify httpd.conf. However, you can implement this by adding following line in .htaccess file.

Header append X-FRAME-OPTIONS "SAMEORIGIN"

How to verify the implementation?

You can use any web developer tool to view Response headers and ensure you see following. You can also use online tool – Header Checker to verify.

Originally posted on http://chandank.com/webservers/apache/secure-apache-from-clickjacking-with-x-frame-options

Secure cookie with HttpOnly and Secure flag in Apache

Apache Security

Do you know you can mitigate most common XSS attack using HttpOnly and Secure flag with your cookie? XSS is dangerous, very dangerous. By looking at increasing number of XSS attack on daily basis, you must secure you web applications.

Without having HttpOnly and Secure flag in HTTP response header, it is possible to steal or manipulate web application session and cookies. It’s good practice to set HttpOnly and Secure flag in application code by developers. However, due to bad programming or developers’ unawareness it comes to Web Infrastructures.

I will not talk about how to set these at code level. You can refer here.

While performing security test on web applications, it’s expected that you will have to fix these to pass the penetration test. This is how you can fix these in Apache Web Server.

Implement in Apache:

1.     Ensure you have mod_headers.so enabled in Apache instance

2.     Add following entry in httpd.conf

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

3.     Restart Apache Web Server

Note: Header edit is not compatible with lower than Apache 2.2.4 version. You can use following to set HttpOnly and Secure flag in lower than 2.2.4 version. Thanks to Ytse for sharing this information.

Header set Set-Cookie HttpOnly;Secure

Verification:

Open your website with HTTP Watch, Live HTTP Header or HTTP Header Online tool.

Check HTTP response header, you should see as highlighted

 

Originally posted by : http://chandank.com/webservers/apache/httponly-secure-cookie-apache

Format Date according to User’s Date Format.

SugarCrm

Quite recently, I faced an issue wherein I have to push some calculated date(based on some algo) to the date field on EditView of a custom module.

My custom function calculated date in dd/mm/yyyy format but the user can have any possible date formats defined by SugarCRM.

Before pushing my calculated date i need to format this date according to user’s settings.

I came through this intelligent post from Johndope http://johndopenotes.wordpress.com/2013/03/05/sugarcrm-format-date-according-to-user-timezone/.

I did little modifications in the code and hurray it solved my problem.

global $current_user; // Instantiate the TimeDate Class
$timeDate = new TimeDate();
$sampleDate = '2014-08-28'; // Sample date.
// Call the function
$FormatedDate = $timeDate->to_display_date($sampleDate, true, true, $current_user);
echo "Date->".$FormatedDate;
//If you want to get time too use the following code.
$sampleDateTime = '2014-08-28 08:00:00'; // Sample date.
// Call the function
$FormatedDateTime = $timeDate->to_display_date_time($sampleDateTime, true, true, $current_user);
echo "DateTime->".$FormatedDateTime;

 

 

HOWTO: Using the bean instead of SQL all the time.

Sugar Developer Blog - SugarCRM

Editor’s Note: This has become one of the most popular posts on the developer blog, so thank you everyone for your interest.

Do note that if you are using Sugar 6.3 or later, check out this post for an even easier way to load beans.

I had one of our community members who likes to “keep us honest” call me out the other day on Twitter…

And he was referring to a post we did where we did some raw SQL queries in the code example. I’ve updated the code examples since then to be correct. And Jeff don’t worry, as you rightfully so called us out on slipping a bit from our normal quality here :-).

But to start off, why is this important? Here’s a few reasons…

• Code portability. Even the most conservative SQL code can have issues on a DB you haven’t tested you add-on against. If…

View original post 899 more words

SugarCRM Cookbook – SugarQuery – The Basics

Sugar Developer Blog - SugarCRM

You have found yourself in a bind, and you need to query the database directly. There is no other recourse than to write a query to get the data you need. This cookbook entry is going to give you some examples on how to use our new SugarQuery API instead of direct SQL.

1. What is SugarQuery?

SugarQuery is a SQL query builder for retrieving data directly from the database.  It is used extensively within the core of the application.  For instance, the FilterAPI uses it.

It uses a bean, the beans relationships, and visibility models to build a SQL query that can be used to retrieve data.

2. The Basics

SugarQuery has a very simple interface for building queries.

The basic methods you will need to create a query are:

• select($fields) – accepts an array of fields you would like to select
• from($bean) – validates the query against a SugarBean at generation
• where()…

View original post 780 more words

HOWTO: Add your own admin panels

Sugar Developer Blog - SugarCRM

Many of you who develop modules on SugarForge or for your own Sugar instance often find the need to add in administration functionality for it. This maybe use to control features or functionality of the module, or perhaps define some defaults that are used in the module. Fortunately, the ability to add these panels as a part of the existing admin section is a very easy and upgrade-safe task.

You can define new admin items in the custom/Extension/modules/Administration/Ext/Administration/ directory, creating a new .php file in that directory to hold the admin items. There are two parts to defining this; in the first part we will define the actual admin panels we will be adding.

$admin_options_defs=array(); $admin_options_defs['MODULENAME']['ADMINPANEL1']=array(        'MODULENAME',         'LBL_ADMINPANEL1_TITLE',         'LBL_ADMINPANEL1_DESC',         './index.php?module=MODULENAME&action=ADMINPANEL1VIEW' ); $admin_options_defs['MODULENAME']['ADMINPANEL2']=array(        'MODULENAME',         'LBL_ADMINPANEL2_TITLE',         'LBL_ADMINPANEL2_DESC'…

View original post 75 more words

Preventing XSS Attacks

XSS Attacks

In my last post I explained you what an XSS attack mean in this post I will explain how can we prevent such attacks.

Preventing a webpage from an XSS attack should always be there in your mind.You can better create a function that prevents these attacks and call it everytime.Fortunately its very simple to prevent these attacks.You should never trust a user that he or she will always input proper data.There are millions of attackers sitting online just to find a prey.

Every bit of data must be validated on input and escaped on output. This is the golden rule of preventing XSS.

To prevent attacks we should follow data validation,data sanitization and output escaping.

Data Validation

It is a process where you validate data according to its requirement.Every piece of data must be validated.

Eg : When you want to validate a phone number you should only allow the user to enter numbers and discard strings or characters.And if you want to allow some special characters like “plus”,”brackets” or “dashes” as such characters are also an acceptable phone format you may use a regular expression for same.

<?php
// validates an Indian mobile number
if (preg_match('^((\\+91-?)|0)?[0-9]{10}$', $phone)) {
    echo $phone . " is valid format.";
}

Data Sanitization

Its a process where you clean up the data by removing any unwanted bits.

Eg : You may want to remove all HTML markups from the data.

<?php
// sanitize HTML from the comment
$comment = strip_tags($_POST["comment"]);

Output Escaping

When presenting the data as output via a browser the output should be escaped to protect its meaning.

<?php
// escape output sent to the browser
echo "You searched for: " . htmlspecialchars($_GET["query"]);

Summary

Never trust the data coming from users and take all required actions to prevent such attacks.You can prevent them with Data Validation and Sanitization and also by escaping Output to protect users.

 

 

 

HOWTO: Create a Flex Relate for other modules

Sugar Developer Blog - SugarCRM

You may recall seeing this field in the various activity modules in Sugar:

This is what’s known as the “Flex Relate” field, which allows you to relate a record to one in a different module that you specify. This allows you to create a relationship where the target entity is flexible, which allows you to represent all sorts of business logic clearly. A great example of this the various activity entities in the app ( Calls, Meetings, Tasks ), which make it so you can relate the activity to one of many different record types.

The only downside of this field, is there’s no good way to build it using Module Builder or Studio ( or least in a very useful way ). However, it’s a pretty easy code customization you can do which is upgrade-safe. Let’s look at how.

We’ll assume we made a new custom module via Module…

View original post 530 more words

Cross Site Scripting Attacks (XSS)

 

XSS Attacks

An XSS attack is one of the top most tried out attacks on a PHP enabled system and your PHP script may not be immune.

This attack is made by injection of code via a web form. The code injected can be any malicious client-side code, such as JavaScript, VBScript, HTML, CSS, Flash, and others. The code is used to save harmful data on the server or perform a malicious action within the user’s browser.

Sadly , many developers fails to deliver a secure code thus open to attacks.Every programmer should consider such attacks and vulnerabilities and try to make the program or script free from getting attacked.

Example

Let me give you an example which will explain you how does such attacks happen.

Below is an index.php page with the following code.

<form method="post" action="save.php">
   <input type = "text" name = "name">
   <input type="submit" name="submit" value="Save">
</form>

In the above html code there is a simple form with a textbox and submit button.On click of the button the form is submitted to save.php for further processing.

A genuine user will fillup his/her name but an attacker can inject code instead of name.

Suppose on save.php just prints out the name.

   echo $_POST['name'];

Suppose instead of writing a plane name the attacker inputs <script>alert(‘HaHa You are attacked!!’);</script>.

If the scripts are not filtered the user will see the popup with message “HaHa You are attacked!! “.

Such JavaScript alert messages though are not harmful still are malicious.But think about what could happen in the JavaScript code was written to steal a user’s cookie and extract sensitive information from it? There are far worse XSS attacks than a simple alert() call.

Types of XSS Attacks

1. Non-Persistent : The kind of attack shown in the above example falls under this category.It means attacks in which the code is not actually stored on the server but is rather presented to the user.
2. Persistent : This attack is more dangerous one in which the code is actually injected into server.

Summary

Hopefully this article gave you a good explanation of what cross-site scripting attacks are.Never trust data coming from the user or from any other third party sources.In my next post I’ll explain how these attacks can be prevented.