I use codeigniter as my framework and in the top of my controllers I am going to add a line of code that will send the uri_string (the last page the user requested) to a library which will send it into the users session and possibly eventually into a database.
My question is whether or not I need to validate this uri_string() at all or whether it is safe as is?
Simple answer, if in doubt validate it.
For the short time it will take you to code it you will have peace of mind.
Also, if this is going to happen for all you controllers may I suggest that you either add the function call to the construct of each controller or extend the core controller to include the call in its construct.
Keep in mind that the 'permitted_uri_chars' item in config.php will automatically prohibit any URL that contains non-permitted characters. So, as long as you haven't modified that to include potentially malicious characters, you should be ok. From the comments in config.php:
By default only these are allowed: a-z 0-9~%.:_-
However, as Rooneyl mentions, it probably wouldn't hurt anything to sanitize it anyway.
Related
I'm new to backend programming. I chose the laravel framework. Already learned the basics. During the study, the question arose: is it necessary to use the form to transfer data to the server ?. For example: the deletion route looks like this to me
Delete.
If I leave it, will it be a mistake? Maybe advise an article or something. Thanks in advance
Short answer is no, it's not necessary, but you should (if you're bound to HTML only).
The HTTP standard has different methods for different purposes. Using an anchor tag will always make a HTTP GET request to the link/server, which is not ideal, GET request should never change the remote (server) state, that's a job other methods (POST, PUT, DELETE, PATCH), you should try to use the method that better describe what you're trying to do: in your case I suppose you're trying to delete a complaint, so a DELETE or POST is what you're looking for.
The only way to use make a non GET request in plain HTML* is to use <form>. Also if you're planning to use a method different from POST you should take a look at Laravel's #method here
Mind that if you can and want to use JavaScript to perform your request you totally can, dropping the requirement to have use form (docs and docs).
I'm guessing no. Here's the situation I have in mind:
form action='/12345/destroy', method='POST'
- if #current_user.kind_of? Admin
button
- else
span You cant do that
What's the better way to go about constructing a page like this? Create a controller for those "in charge" and have the buttons there? What if the admin chooses to disallow some users from using the delete button, are we back to square one? Thanks
Your example is perfectly fine IMHO, but it really depends on your requirements. If you think that someday there will be the need for more kinds of users and you're afraid the views could get messy, I'd recommend looking into an ACL library. Alternatively you can always roll your own authorization layer.
Your view is fine, but obviously, it is in no way secure. You have to check the privileges in your "controller" (if you have one) or in that request's receiving end.
Also, that logic will probably be used in more than one place. You might consider extracting it into a helper method.
form action='/12345/destroy', method='POST'
= render_destroy_action_for #current_user
Once you have that logic hidden in a method, it will be easier to change later.
We usually follow the convention of doing a redirect after every post, which is ideally very clean. But usually there is a requirement to give the user feedback about what has been updated.
When i do a post followed by get i wanna show the same page with the notification about the updation being done, which makes the GET very clumsy with the extra status of whats being updated. Am i missing something here?
which is ideally very clean
debatable.
which makes the GET very clumsy with the extra status of whats being updated
...and that's one of the main reasons why.
Trying to pass transactional data via the session is a very bad practice.
The solution I've used is to use a front controller for sequences of forms (not a front controller for the whole site!) but in general trying to avoid the scenario where there is a sequence of forms to be posted
Why does CodeIgniter's XSS filter only react through regular expressions on specific things instead of sanitizing all input in the first place regardless if the content is tainted or not? Also, why is this done during input and not on output (like it's supposed to be?)
Why does CodeIgniter's XSS filter only react through regular expressions on specific things instead of sanitizing all input in the first place regardless if the content is tainted or not?
This doesn't make much sense. How are we to tell whether or not something is "tainted" without checking it first?
By the definition of CI's xss_clean(), we don't always want to sanitize input. As you mentioned, it's the output that matters - and that's where we need to be mindful of XSS atacks. If we always "sanitize" input with CI's xss_clean(), then how would I, for one example, be able to post javascript or PHP code examples on my blog, or let users do it in the comments? It would end up getting [removed].
Also, why is this done during input and not on output (like it's supposed to be?)
You do have the option to enable the global xss filter in your CI config, which will run xss_clean() on $_POST, $_GET, and $_COOKIE data automatically before you can get your hands on it. This is the lowest level possible to protect you from yourself, bu the option is always available to instead clean the data explicitly. For example:
// With the Input class on $_POST data
$this->input->post('username', TRUE); // Second parameter runs xss_clean
// Using the Security class on any data
$this->security->xss_clean($username);
// Using the Form Validation class to automatically clean the input
$this->form_validation->set_rules('username', '', 'xss_clean');
Since you could still simply use $_POST['username'] instead, by enabling the global filter it will already be xss_cleaned for you. This is the lazy way to do it, and unfortunately once those globals are cleaned, there's no way to undo it.
If you are already aware of when and where XSS attacks can happen - you have the function easily available to use if you wish. Keep in mind that this does not magically make all data "safe", it merely prevents some of the more malicious code injection. Something more harmless like </div> will get past this filter. You should always be sanitizing input explicitly in an appropriate way for the context in which it is used.
I was just wondering if it is possible to ignore the last URI segment of my application via either mod_rewrite or CodeIgniter. I don't want a redirect away or a remove the URI segment. I just want my app to not know it exists. So in the browser the client will see:
http://example.com/keep/keep/ignore/
but the app is only aware of:
http://example.com/keep/keep/
The idea is, if JavaScript detects /ignore/ in the URI, it will trigger an action.
/ignore/ may appear as 1st, 2nd, 3rd or 4th segment, but will only ever appear as the final one and may sometimes not appear at all.
I found some info online about ignoring sub-directories with mod-rewrite, but none of them really work like this.
**
Incase any CodeIgniters suggest passing it as an unused extra parameter to my method - The app has far too many controllers and far too many wildcard routes for this to work site wide.
I think a mod_rewrite solution would be best if possible. If not, perhaps it can be done with a CodeIgniter pre-controller hook or something, but I'm not sure how that would work.
EDIT: How I got it to work
For anyone else who would ever like to know the same thing - in the end I overwrote _explode_segments() in MY_URI to not include this segment.
With the URI class you can check and detect what URI's are and what they have.
$this->uri->segment(n)
Check out the user guide: http://codeigniter.com/user_guide/libraries/uri.html