I have always wondered when you do web forms on your website whether it is sign up forms or search field, you give away your field name so is that a security risk or no? What's the best way to prevent that?
E.g: <input name="person_name">
It is not a security risk, it is just a name that becomes the key part in the params.
Please don't try to prevent SQL injection attacks by escaping characters. Use the PDO API to create parameterized queries. See the PDO manual on Prepared Statements
Not using the same database column names and HTML form field names is security by obscurity at best.
Related
I'm building a CRUD for users in my rest API, and currently my GET route looks like this:
get("/api/users/:id")
But this just occured to me: what if a users tries to search for other users via their username?
So I thought about implementing another route, like so:
get("api/users/username/:id")
But this just looks a bit reduntant to me. Even more so if ever my app should allow searching for actual names as well. Would I then need 3 routes?
So in this wonderful community, are there any experienced web developers that could tell me how they would handle having to search for a user via their username?
Obs: if you need more details, just comment about it and I'll promptly update my question 🙃
how they would handle having to search for a user via their username?
How would you support this on a web site?
You would probably have a form; that form would have an input control that would allow the user to provide a user name. When the user submit the form, the browser would copy the form input controls into an application/x-www-form-urlencoded document (as described by the HTTP standard), then substitute that document as the query_part of the form action, and submit the query.
So the resulting request would perhaps look like
GET /api/users?username=GuiMendel HTTP/x.y
You could, of course, have as many different forms as you like, with different combinations of input controls. Some of those forms might share actions, but not necessarily.
so I could just have my controller for GET "/api/users" redirect to an action based on the inputs?
REST doesn't care about "controllers" -- that's an implementation detail; the whole point is that the client doesn't need to know how the server produces a representation of the resource, we just need to know how to ask for it (via the "uniform interface").
Your routing framework might care a great deal, but again that's just another implementation detail hiding behind the facade.
for example, there were no inputs, it would return all users (index), but with the input you suggested, it would filter out only users whose usernames matched the input? Did I get it right?
Yup, that's fine.
From the point of view of a REST client
/api/users
/api/users?username=GuiMendel
These identify different resources; the two resources don't have to have any meaningful relationship with each other at all. The machines don't care (human beings do care, so we normally design our identifiers in such a way that at least some human beings have an easy time of it -- for example, we might optimize our identifiers to make things easy when operators are reading the access logs).
I am planning on using the lift's mapper's megaprotouser and I am wondering if I need to hash the passwords before they are inserted into the database, or does it already take care of that?
The MegaProtoUser will not obscure the password by itself, but it uses MappedPassword, which provides that functionality. Check https://github.com/lift/framework/blob/master/persistence/mapper/src/main/scala/net/liftweb/mapper/MappedPassword.scala to see how this is achieved.
I am trying to find a way to test and verify my form validation is doing all it can to protect me from script injections. Is there a tool that I can use to test and verify my forms for any known vulnerabilities.
Are you talking about Webdevelopment?
You should prevalidate your forms using javascript or jquery logic. But this will not bring you any security, it will just reduce server traffic, because non valid forms will not be send to the server doing so.
Further more you have to validate your forms at the server using php or what ever you use on server side.
Do not forget to use htmlspecialchars whenever you display variable input values to be aware of xss attacks.
Use mysqlrealescapestring or some escaping for the dbs you are using. If you use an orm escaping is mostly done automaticly.
you asked for a tool? you can use the zend framework, it is complicated but it has some form validation automatisms.
E.g: you can validate ISBN numbers, email addresses or bar codes with it automatically.
I noticed this question was never answered well enough for me to except an answer. I ended up using a form fuzzer. A browser add on like this https://addons.mozilla.org/en-US/firefox/addon/immuniweb-self-fuzzer/ will enter data into the form inputs and try to break your form validation inputing various kinds of data. Best to work on a development/sandbox type environment since the data input an potentially destroy your database.
I need some opinions.
I'm going to develop a POS and inventory software for a friend. This is a one man small scale project so I want to make the architecture as simple as possible.
I'm using Winform to develop the GUI (web interface doesn't make sense for POS software). For the database, I am using Postgresql.
The program will control access based on user roles, so either I have to develop a middle tier, using a web server, to control user access or I can just set user priveleges directly in Postgresql.
Developing a middle tier will be time consuming, and the maintenance will be more complex. So I prefer to set access control directly in the database.
Now it appears that using database to control user access is troublesome. I have to set priveleges for each role. Not to mention that for some tables, the priveleges are at column level. This makes reasoning about the security very hard.
So what I'm doing now is to set all the tables to be inaccessible except by superusers. The program will connect to the database using public role. Because the tables are inaccessible by public, I'm going to make publicly accessible stored functions with SECURITY DEFINER (with superuser role). The only way to access the tables is by using these functions.
I'll put the user roles and passwords in a table. Because the user table itself is inaccessible by non-superuser, I'll make a login function, let's call it fn_login(username, password). fn_login will return a session key if login is successful.
To call other functions, we need to supply session key for the user, e.g.: fn_purchase_list(session_key), fn_purchase_new(session_key, purchase_id, ...).
That way, I'm treating the stored functions as APIs. Adding new user will be easier as I only need to add new rows in the user table rather than adding new Postgresql roles. I won't need to set priveleges at column level. All controls will be done programmatically.
So what do you think? Is this approach feasible and scalable? Is there a better way to do it?
Thanks!
I believe there is a better way to do it. But since you haven't discussed what type of security you need, I cannot elaborate on specifics.
Since you are developing the application code in .NET, that code needs to be trusted (unlike a web application). Therefore, why don't you simply implement your roles and permissions in the application code, rather than the database?
My concern with your stated approach is the human overhead of stored procedures. Would much rather see you write the stated functions in C#, rather than in PostgreSQL. Then, standard version control and software development techniques could apply.
If you wait until somebody has at your database to check security, I think you'll be too late. That's a client/server mentality that went out at the end of the 90s. It's part of the reason why n-tier architectures came into vogue. Client/server can't scale horizontally as well as an n-tier solution.
I'd advise that you take better advantage of the middle tier. Security should be a cross-cutting concern that's further up the stack than your persistence layer.
If the MANAGEMENT of the database security is the issue, then you should add the task of automating that management. That means that you can store higher level data with the database tables, and then your application can convert that data in to the appropriate details and artifacts that the database requires.
It sounds like the database has the detail that you need, you just need to facilitate the management of that detail, and roll that in to your app.
My honest advice: Do not invent POS and inventory software. Take one of existing projects and make it better.
I'm currently in the process of developing a GWT 1.7.1 application that deals with a significant amount of persistent, user generated data so there is a risk of malicious XSS. One of the steps I am taking to prevent this is using org.apache.commons.lang.StringEscapeUtils.escapeHtml() server-side (Yes I am well aware that this will not prevent all possible XSS attacks as mentioned here and here).
This approach is causing a client-side problem since it appears that GWT is performing it's own client-side escaping (e.g. The server returns the string “Alice & Bob Inc.” and “Alice & Bob Inc.” is being rendered to the DOM which is incorrect). This is definitely happening client-side as the http response from the server contains the correctly encoded data. I have been going through the documentation for GWT and haven't found any reference to this feature. Is anyone aware of a way of disabling this behaviour?
How are you adding the value the server returns to the page? Could you be adding at as text? If you are sure the String is safe you can add it as HTML (there is usually an option for HTML) or specific Widgets like HTML.
btw Usually best not to return HTML encoded values from the server as you don't know how you may want to use them. I use the rule that you keep the values in their clean format till the last minute (adding to the document etc).