What can I do?

Hi everyone!
This week I've been thinking about how to implement authorization in umitWeb. In other words, I've been trying to define a way to determine what users can or cannot do running nmap on UmitWeb (once UmitWeb every run as root on the server).

After few days I 'compiled' a mockup that how it will work. The mechanism is quite simple: each User will be assigned to a Role, and that role can have several Access Permissions. This appear to be an obvious way to do authorization. But how could access divided in permissions?

I found a way that I guess it's interesting: each Role will have definitions about details of command composition. For example, a Role to an user that can execute OS detection will have a permission to execute nmap with the '-O' parameter. In other hand, if a role doesn't have a permission that define the '-sV' command, users assigned to that role cannot do detection of service's versions.

The better way to find this option inside the nmap command line is comparing it with regular expressions. There are advantages to use regular expressions to indentify parts of a command. The permission definition can me written in an XML file (like options and profiles), and it can be extended by the user. For example, if a user like to create a new permission definition, He/she can easily do it by editing the security.xml and put inside it the properly regular expression associated with that permission.

I'm still thinking if the best way to store user roles is in XML files or a database. I have this issue to store users too. I'll realize tests and researches about security issues in each case.

Next week will be time to implement my thoughts and test it. Let's roll in the first official GSoC week. Here we go!

First scan through the web

Hi folks!

Like the first step of a child, I'm glad to annouce the first remote scan did by UmitWeb. There is a screenshot.
This first scan don't look very beautiful, but it's working now, doing scans based on a nmap command typed in a text box. Oh, I need to mention that it is working with AJAX by now.

Ok, no more news by now. I'll post more things soon.

Serving to the web

Last night I finished to write the UmitWeb's web server. I worked hard, and it's working fine now. I would like to introduce you some features included in this 'bundled' server:

• Elegant URL Mapping
• GET and POST parameters
• File upload
• Cookies
  
• Session
  
  

Elegant URL Mapping

I am a django developer, and I like so much the way that it handles the URL passed by the user. In an url config module, we type some url patterns (using regular expressions), and assign each pattern with a function, that must returns a HttpResponse. I did a work likes this, handling URLs by matching them with regular expressions, associated with functions that are called, each at their time.

GET and POST parameters

This is basic functions that are essential for a web browser. GET (via URL) and POST (via request body) methods are handled in a class called HttpRequest, that encapsulate these attributes in a 'pythonic way' (stored on dictionaries).

File Upload

UmitWeb must be able to manage uploaded files (like options, profiles and result scans), so its web server must work with file upload. This feature is working by handling multipart/form-data requests content-types, that works different from the default POST request (x-www-urlencoded). This took a more longer time, and a specia attention, but all about it is working fine now.

Cookies

Another important feature. Cookies can store variables in the client web browser. It is good, but it is bad too. Cookies can make your application insecure, and can be a security hole, but it is so useful (and also essential) when we work with sessions.

Session

Sessions are NOT a HTTP standard, but it has been used by several web servers to store data in a secure way: A cookie is sent to the web browser, with the value of you session's ID. This session ID is associated, in the server, with a dictionary that store data about that session. This dictionary is serialized and stored in a SQLite database. When the users closes the browser, or when he finishes the sessions, all information is destroyed.


Ok, that's all for a while. I shall write more posts about the UmitWeb project soon.

Hurry Up!

Hi folks!
I'm starting writing this blog, to share with everyone the status of UmitWeb project, sponsored by google.
There's no much time to waste, then I'll write and write (code and blog posts XD ) as faster as I can.

Then... Let's do the work!