You are currently browsing the archives for the annoucement category.

Posted on May 7, 2008 at 2:02 pm

Now introducing METApic

Its my distinct please to announce my latest ’side’ project.

METApic

Metapic is a Digital Asset Management system that tries to be as generic as possible. Find all the details at my METApic page

Posted on April 24, 2008 at 5:22 pm

Rochester Crusader’s truck broken into

Its been a busy week,

On tuesday the Rochester Crusaders equipment truck was broken into, with about $40k of damage :-(

WROC 8 covered the crime

Here are just a few of the pictures i took of the carnage. You can see the whole set at my Flickr page. 

Cru Vandalizm
Cru Vandalizm

Cru Vandalizm

Posted on March 31, 2008 at 3:16 pm

Netboot Across Subnets

Rob wrote a great article on how to Netboot your macs across multiple subnets, like we do here at RIT

cias.rit.edu/~rrhpph/wordpress/

Posted on February 28, 2008 at 10:22 pm

Wildcard Certificate on cias.rit.edu

Earlier today we installed a wildcard certificate on cias.rit.edu.

What does this mean?

A: Before today, if you went to https://bjcpgd.cias.rit.edu (over SSL) you would be using the certifcate for cias.rit.edu, and in the eyes of your browser bjcpgd.cias.rit.edu and cias.rit.edu are two totally seperate domains. The installation of this wildcard certifcate now means that the certificate will cover and be valid for all sub-domains of cias.rit.edu. This means you can now easily use SSL to protect your web applications on cias.rit.edu.

Do I have to change anything to use this certificate?

A: Not at all! The certificate is active and valid for all accounts under cias.rit.edu. You may need to tweak your application to make sure its point to https:// in the areas that you want protected, but that is a very application specific issue.

What else has the cias tech team been doing to help secure our applications and data on cias.rit.edu?

A: In the past we have allowed all users to be able to browse other users directories. We’ve been slightly uncomfortable with this scenario for a while. Yesterday we made a change to everyone’s home directory that will keep prying eyes out, yet still allow your web applications to ‘roam free’. We specificly did the follow on each users home directory:

    chgrp www-data /home/<username>    chmod 750 /home/<username>

What exactly did that just do? First off we made the group owner for you home directory the web server’s user. So you are the owner of your directory, and www-data is the group. The chmod of 750 means, The owner can read,write and execute. The group can read and write, everyone else has NO ACCESS.

 

Posted on February 4, 2008 at 4:45 pm

Securing your PHP Upload scripts

Security should always be on the mind of any developer of web technologies, but sadly in todays rush toward rapid application development and fast approaching deadlines, security takes a backseat sometimes. Here at CIAS we need to walk the thin line between a locked down and secure web environment, and an open and available environment which allows Students, Faculty and Staff the ability to freely explore all aspects of web programming.

We have had a few incidents involving unsecured uploads scripts on the cias.rit.edu student web server, so we need to start taking a harder look at security. These incidents have involved both spam, and hacking attempts.

There are two ways I can look at the security of the cias.rit.edu web applications.

  1. I can lock down apache and php and make it nearly impossible for hacking attempts, at the expense of your ability to create flexible web applications.
  2. I allow the responsibility to come down to the individual account owners to secure their applications and keep security of the server as their primary priority.

I would much rather latter option, the first option creates an environment that is very much limiting and locked down.

With that said, what can you as a developer do to help secure our environment in your file upload scripts??

Here are some simple steps you can take in your scripts:

  • Check the referrer of the form submission: make sure the information being sent from your script actually come from your script, not being faked from an outside source
  • Restrict file types: This is the most important step you can do to secure your file upload scripts. if you are only expecting jpg images, make sure the file being uploaded has the .jpg and/or .jpeg extension. Note to watch out for double extensions (i.e. image.jpg.php )
  • Rename the file being uploaded: If the image comes in as MyCutePuppy.jpg, rename it to something like timestamp_MyCutePuppy.jpg, or even better yet, if you are keeping your images in a database, you can easily track the names of your files if you rename them to something completely random, such as a timestamp or md5 checksum
  • Permissions: 777 is not a good idea for your unless you REALLY need it. The best idea is at least 644 ( Owner can read/write/, everyone else can only read) This is a perfect for image uploads, if you are doing things in your web app such as deleting images, you may need to loosen up your permissions, but make sure you don't just blanket 777 everything, as this 'is a bad idea'
  • You will need your upload directory to be 777, but all the files in it should be 644
  • Make your users login, or at least give some information that you can use to track them down. Actions like this will deter users (or bots) from doing 'bad' things

Ok, so with these nice little tips, how can we create a nice easy php upload script that won't allow the server to be owned?

Well, to understand that, I think we need to understand how an unsecured upload script can be exploited, here is a great example, and exactly how we've been attacked before.

  1. Hacker finds an unsecured upload script
  2. Hacker uploads a .php file
  3. Hacker then finds his .php that was uploaded to the server, not renamed and with 777 permissions. By just visiting this PHP script in his web browser the attack has started
  4. That PHP scripts then proceeds to download from the internet binaries and other php scripts that can be used to gain a command line on the machine
  5. The hacker now has the run of the server as the user www-data who runs the apache server. This is a bad situation, this has now put every account on the web server at risk, because the www-data user has permissions to everyone's directory.
  6. The hacker at this point can either launch attacks on other servers, using our good name as a proxy, or can continue to exploit our server and install software that gives the hacker a backdoor.

As you can see, this 'is a bad thing'

So how do we stop this from happening?!

The following script gives you everything you need! (Read the comments to understand what everything does)
The sample script implements many of the points i talked about earlier in this post, ejoy

You can try out the script, and see the source at: http://bjcpgd.cias.rit.edu/upload.php

 

 

PLAIN TEXT
PHP:
  1. <h2>CIAS Secure PHP File Upload Example</h2>
  2. <!-- The data encoding type, enctype, MUST be specified as below -->
  3. <form enctype="multipart/form-data" action="upload.php" method="POST">
  4.     <!-- Name of input element determines name in $_FILES array -->
  5.     Send this file: <input name="userfile" type="file" />
  6.     <input type="submit" value="Send File" />
  7. </form>
  8. <hr>
  9.  
  10. <?php
  11.  
  12. #This is an array which you can manage to determine which file types you want to allow to upload
  13. $allowedFileTypes = array("jpg","png","bmp","gif","pdf");
  14.  
  15. #This is where you want to upload, this directory much be writable by the webserver (777 on cias.rit.edu)
  16. $uploaddir = 'sample_upload_directory/';
  17.  
  18. #This is a statement that will kill your script if your upload directory doesn't exist and isn't writeable by the webserver
  19. if(!is_dir($uploaddir) && !is_writable($uploaddir)) {
  20.     echo "Your upload directory has not been created or setup properly!!";
  21.     die();
  22. }
  23.  
  24.  
  25. #We define and rename the file here, I've simply tacked on a timestamp, but you can get creative if you want
  26. $uploadfile = $uploaddir . time()."_".basename($_FILES['userfile']['name']);
  27.  
  28. #We now get some information about the file, so we can check its extension
  29. $uploadfileinfo = pathinfo($_FILES['userfile']['name']);
  30.  
  31. #In this line we are making sure that our upload script is being run from... our upload script,
  32. #You can replace $_SERVER['SCRIPT_URI'] with the name of the URL you expect your script to be run from. (ie a sperate upload.html file)
  33. if($_SERVER['SCRIPT_URI'] == $_SERVER['HTTP_REFERER']) {
  34.    
  35.     #Lets make sure our POST variable exists and that the form has been submitted
  36.     if(isset($_POST)) {
  37.  
  38.         #This checks if our uploaded file has an extension that we set up in the $allowedFileTypes array above
  39.         if(in_array($uploadfileinfo['extension'],$allowedFileTypes) ) {
  40.            
  41.             #Ok, this statement actually moves the uploaded from the tmp directory to our final destination
  42.             if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
  43.                 chmod($uploadfile, 0644);
  44.                
  45.                 #Ok, everything has been uploaded just fine, this is where you would update your MySQL database,
  46.                 #or any other manipulation you need to do
  47.                
  48.                 echo "File is valid, and was successfully uploaded.<br/>\n";
  49.                 echo "View file: <a href='$uploadfile'>here</a>";
  50.                 echo "<pre>";
  51.                 print_r($uploadfileinfo);
  52.                 echo "</pre>";
  53.             } else {
  54.                 #This else statement really just means, something happened in your upload and you got an error
  55.                 echo "Possible file upload attack!\n";
  56.             }
  57.  
  58.         } else {
  59.             #This is where you would handle your 'not allowed' extentions.
  60.             echo "The file: ". $uploadfileinfo['basename'] ."  is not an allowed file type";
  61.         }
  62.     }
  63. }
  64. ?>

Posted on January 31, 2008 at 2:55 pm

RIP Heinz Klinkon

 
Heinz Klinkon, Associate Professor, Department of Graphic Design, College of Imaging Arts & Sciences passed away on January 27, 2008. He was a valued colleague of the faculty and a beloved teacher to his many students. 
 
He studied at the Gewerbeschule, Offenburg in Germany, Corcoran School of Art and RIT, receiving a BFA in 1979 and a MFA in 1990. Prior to coming to RIT to teach, he had worked at two prestigious design firms, Beveridge Associates in Washington DC and Chermayeff and Geismar in New York.  Vignelli Professor R. Roger Remington remembers that when Heinz was studying at RIT, “he had already been working in a top firm before and upon his arrival was already a better designer than several of his teachers. So, a few years later, when he was ready to leave New York, I proudly hired him right away.” 
 
Heinz said about his teaching, “I teach the skills, concepts and critical approaches required for successful creative work in the graphic design field. My approach emphasizes semiotics, thorough and systematic analysis, the integration of aesthetic, verbal and functional elements, realistic projects including portfolio completion to a substantial level of professional self consciousness and confidence.”
 
He joined the RIT faculty in 1981, was tenured in 1991 and received Associate Professor rank in 1993.  His design work appeared in many publications and appeared in numerous exhibitions. For a number for years he has created provocative sculptures, many of which have appeared in Faculty Exhibits in Bevier Gallery.
 
 
 
 

Posted on January 19, 2007 at 12:55 am

Sent to all webserver users

The following message was sent to all CIAS Web server users tonight:


Dear web server users,

An exciting new feature was released tonight (1/18/2007)!
I would like to make you aware of a very nice new feature that has justbeen activated on the cias.rit.edu web server.
From now on you can either address your web space via the standard:
http://cias.rit.edu/~bjcpgd/
or the new:
http://bjcpgd.cias.rit.edu/

This new address gives your web space a bit more personality anduniqueness.

Enjoy your new personalized sub domain and if you have any suggestionsor new features you would like to see, or just general feedback pleaseemail me at:
bjcpgd@rit.edu
or comment on my blog at
http://bjcpgd.cias.rit.edu

Thank you for your time

~Brad

Posted on January 19, 2007 at 12:31 am

Virtual sub domains

Well, this is feature i've been wanting to implement for a while.

Virtual Sub domains for mod_userdir

I created a dns entry for *.cias.rit.edu
All request coming to the server are then handled by mod_rewrite which goes ahead and redirects requests to their proper mod_userdir

This little 3 liner at the top of my mod_rewrite rules (which is becoming a very long list in maintenance of this web server is all i needed to convert from ~ to .cias.rit.edu


PLAIN TEXT
CODE:
  1. rewriteCond %{HTTP_HOST} !^cias\.rit\.edu
  2. rewriteCond %{HTTP_HOST} ^([^.]+)\.cias\.rit\.edu
  3. rewriteRule (.*) /~%1/public_html/$1 [L]




I am very excited about, as it creates more of a unique identity for web space on the cias server.

Also, tonight i went and upgraded the memory in the server from a measily 512MB, to 2GB, you have to love VMWare where you can just 'give' a machine more memory.

Posted on August 1, 2006 at 11:06 am

CIAS’s expanding world

In the last few years the College of Imaging Arts and Sciences has been expanding its IT infrastructure at a very fast rate.

We have been introducing large amounts of storage, offering web services, developing renderfarm solutions, and keeping our client machines as safe as possible in the increasingly frightening internet