How to return original page from customer CGI Handler? - cgi

I am trying to intercept each and every request using python CGI handler to particular path in Apache 2.4 server and modify the original as required. (This is to validate JWT token stored in cookie)
I am referring the below documentation (http://httpd.apache.org/docs/2.2/handler.html)
Modifying static content using a CGI script The following directives
will cause requests for files with the html extension to trigger the
launch of the footer.pl CGI script.
Action add-footer /cgi-bin/footer.pl
AddHandler add-footer .html
Then the CGI script is responsible for sending the originally
requested document (pointed to by the PATH_TRANSLATED environment
variable) and making whatever modifications or additions are desired.
I am able to reach the handler and validate the JWT token in it.
But, the issue is I don't find a way to sent the original document when the token is valid.

You really should not be using a handler for this task. If you must write your extension in an interpreted language, look at a RewriteMap prg: extension point. Otheriwse, you can write code in a hook meant for access control.
But in the example you show, the injected handler would only work for a static file request. It's just going to something akin to cat'ing the file passes as an argument then writing its own trailing data.

Related

Redirect url based on ID using lua

I'm extremely new to Lua as well as nginx.we're trying to set up authentication.
I'm trying to write a script that could be injected in my NGINX which would actually listen to a an endpoint.
My api would give give me a token. I would receive this token and check if it exists in my YAML file or probably JSON file .
based on the privilege mentioned in the file, I would like to redirect it the respective url with necessary permissions.
Any help would be highly appreciated.
First of all, nginx on its own has no Lua integration whatsoever; so if you just have an nginx server, you can't script it in Lua at all.
What you probably mean is openresty, aka. the lua-nginx-module, which lets you run Lua code in nginx to handle requests programatically.
Assuming that you have a working nginx + lua-nginx-module installed and running, what you're looking for is the rewrite_by_lua directive, which lets you redirect the client to a different address based on their request.
(Realistically, you'd likely want to use rewrite_by_lua_block or rewrite_by_lua_file instead)
Within the Lua block, you can make API calls, execute some logic, etc. and then redirect to some URI internally with ngx.exec or send an actual redirect to the client with ngx.redirect.
If you want to read in a JSON or YAML file, you should do so in the init_by_lua so the file gets loaded only once and then stays in memory. The lua-cjson module comes with nginx, so you can just use that to parse your json data into a Lua table.

How to Prevent Cross-Site Request Forgery Attack?

We ran Burp Suite on our product and found some security vulnerabilities. The tool detected some of the CGI files which are vulnerable to Cross-Site Request Forgery attacks (CSRF).
As usual I did search for CSRF protection module on CPAN and found CGI::Application::Plugin::ProtectCSRF.
I'm wondering how can I integrate this module into our application in a generalized way? The documentation is not clear to me. How do I configure this module and make minimal changes to make sure whole application is secured from CSRF.
I also came across mod_csrf (an Apache module to prevent CSRF). Is installing this module and setting below in apache configuration file enough to prevent CSRF?
<VirtualHost>
CSRF_Enable on
CSRF_Action deny
CSRF_EnableReferer off
</VirtualHost>
I can understand that you found the documentation for CGI::Application::Plugin::ProtectCSRF unclear: it is a little impregnable
All that the Perl module appears to do is to add a hidden field to each HTML form with the name _csrf_id and a random value derived from various sources and encoded through SHA1. The protection comes when the response from the client requires that the same value must be returned to the server
It is quite nicely coded, but it uses custom subroutine attributes, and the documentation for the attributes pragma says this
WARNING: the mechanisms described here are still experimental. Do not rely on the current implementation
I cannot tell from my quick review whether the subroutine prototypes are essential to the module, but I recommend that you use the Apache mod_csrf module instead, which is likely to be more thoroughly tested than the Perl module, and has proper documentation
Since we were using in house server, not apache, therefore, mod_csrf was not possible to implement.
I ditched ProtectCSRF module as the documentation was unclear.
I solved it by doing below:
Add an element in header template which is common to all pages, this element contains CSRF token which is being passed from server
Create a JavaScript function and bind it to onload event. This JS function does below tasks:
a) Find forms in current page
b) If forms are found then create a hidden "input" element and append it to each form
c) Take the value which was put in header and assign it to above created elements
d) Now all forms have a hidden input element which contains CSRF token from point 1
Now whenever a form gets submitted this hidden element will also be submitted, whose value we are verifying at server end. If tokens do not match then there is CSRF, for which we throw the error and block request

Server-side logging of html generated by dynamic site

I'm curious about how to capture the dynamic html generated via php, aspx..., server-side, just as page requests themselves are logged.
Is this a scripting task (using python for instance), a web-server log format configuration setting (I've searched Apache's docs but could only find the usual log formatting directives) or a totally different approach?

What is a pass-through request?

This is spoken in the context of a guide on express.js. Here is the quote:
Static middleware enables pass-through requests for static assets.
Googling doesn't yield a definition like I thought it would.
I think "pass-through" in this context means that static files on disk "pass through" express without any processing or modification and are sent directly to the browser, in contrast to dynamic requests which involve generating new and dynamic HTML in response to a browser request (using templates and databases, perhaps).
For example, we have this code at http://example.org
app.use(express.static(__dirname + '/public'));
app.get('*',function(req, res){
res.send('Hello');
});
For example, we open by browser the url http://example.org/somefile.txt
if there is file of somefile.txt in folder of public/ , it is returned, but if the file doesn't exists, the request is passed to other controllers, in this case to app.get('*',...)
So, the client recieves the response with Hello

Custom .htaccess password protection handler

I need to protect a site that has a ton of static .html files. The standard .htaccess scheme doesn't meet the requirements.
Is there a way to specify an .htaccess style of password protection with a custom handler? That is I need to write the code to determine if the user is allowed or not, but I don't want to modify a million .html files all over the place.
Thanks!
Maybe. It depends on what modules are loaded on your web server. Your options will range from keeping a simple list of users in a flat file, to keeping them in a database and customizing the queries.
http://httpd.apache.org/docs/2.2/howto/auth.html
Another option - just brainstorming here - is to use something like mod_rewrite to redirect the calls to the physical file to something like a PHP script that can manage the user/password authentication for your, and if authenticated, go out and load the html file that was requested. So calls to www.some.com/10203.html actually get directed to www.some.com/auth.php?10203.html, which would control access to that underlying html file. That would of course require mod_rewrite to be installed, which is pretty common even for shared hosting environments.