For a debugging purpose, I want to print a specific cookie value in my access.log or request.log.
One way to do is, from the dispatcherServlet, add a logger for SlingHttpRequest.getCookies(). But this debugging is needed in Production and I cant make java code changes and deploy.
I read the documentation and tried to change the org.apache.sling.commons.log.pattern property in org.apache.sling.commons.log.LogManager.factory.config in the configManager for access.log like this:
{0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5} "%cookie{login-token}"
This didnt help. Able to see date timestamp changed, {2} {3} etc are printing. But as desired, the cookie value is not printing.
How to print the cookie values in http headers in AEM log files?
I don't think the entire documentation that you are referring to is supported OOB. The pattern format in AEM specifically points to the Pattern Layout section of the documentation. As part of that, there is no support for request cookies.
The request cookies section is specifically present under the pattern layout of the Logback access section which states the below
PatternLayout in logback-access can be configured in much the same way
as its classic counterpart. However it features additional conversion
specifiers suited for logging particular bits of information available
only in HTTP servlet requests and HTTP servlet responses.
That being said, the sling logging documentation mentions using a Sling extension for slf4j MDC support which can be used to expose some of the request variables including cookies. Extract from the doco below
The filter allows configuration to extract data from request cookie,
header and parameters. Look for configuration with name 'Apache Sling
Logging MDC Inserting Filter' for details on specifying header,
cookie, param names.
Once the MDC bundle is downloaded and added to your instance, you can use the log back patterns instead of the classic pattern for the log format. Example from the doco shown below.
%d{dd.MM.yyyy HH:mm:ss.SSS} *%p* [%X{req.remoteHost}] [%t] %c %msg%n
Hope this helps.
Related
I have an application that has a VueJs based front end and NodeJs based backend API. The client-side is a SPA and it communicates with API for getting data. Now in a security scan, it is mentioned that the app doesn't have a Permission-Policy HTTP header and I would like to add it. I but not sure is there any option I can add in the VueJS and I am confused whether this is something that needs to be added from the front end. From the Node app, it is possible to set the header, but here the pages are not generated from the server-side. It will be helpful if someone can let me know how can I add these headers to the app.
Technically you can publish Permissions-Policy header when you sent an initial SPA's HTML code (you have to use some packages or Node.js server facility to publish response header). Even more so scanners do not execute ajax and will not see the pages of your SPA.
But there are some doubts whether it is worth doing it at all.
Permissions Policy is a new name of Feature Policy, below I will use Feature Policy term, but all of the below also applies to Permissions Policy.
Browsers poorly support Feature Policy and do not support Permissions Policy. Only Chrome supports the interest-cohort directive, but you have to set specific flags to enable Permissions Policy support. Feature Policy / Permissions Policy spec still is under development.
Feature Policy is rarely published via HTTP header, because it is intended to restrict the capabilities of nested browsing contexts (iframes), and not the main page itself. Therefore it's mostly published via <iframe allow="..." attribute for each third-party iframe embedded.
But the scanners are not aware of this and do not check the allow= attribute.
Scanners don't know much about real security, they are more focused on visualization baubles like Grade A+ and labels with green/red color. Therefore scanners:
are not recognize Content Security Policy in meta tag, just in the HTTP header.
require X-Frame-Options header for any web page despite presence of CSP's frame-ancestors derictive and ignore fact that some sites are inbtended to be embedded (widgets, youtube/vimeo video etc.).
require Feature Policy / Permissions Policy header despite these are not supported or are published by another way.
Mostly scanners results have nothing with real security, all is how to get A+ grade, nothing else (see a relevant thread "headers manipulatin to get Grade A+").
Of course, scanners can draw your attention to some overlooked headlines, but final decision which headers do web-app need to publish is up to you.
I am new to Jmeter and load testing overall but I have read about the Cookie Manager over and over and still can't find the answer to my problem.
The site I am trying to test uses several cookies to authenticate but not all of them are seen in the Jmeter Response Headers. I can see them if I look using the browser but Jmeter doesn't seem to pick them up at all.
If I manually set the cookies in the Cookie Manager after a recent session then the test passes but my concern is that when I use multiple threads, they won't all get individual values and rather just the ones I have specified.
I expect all the cookies that are set to be displayed in the response headers, that way I can set variables etc but out of 3 only one appears in Jmeter.
Please check the below information:-
JMeter checks that received cookies are valid for the URL. This means
that cross-domain cookies are not stored. If you have bugged behaviour
or want Cross-Domain cookies to be used, define the JMeter property
"CookieManager.check.cookies=false".
Received Cookies can be stored as JMeter thread variables. To save
cookies as variables, define the property
"CookieManager.save.cookies=true". Also, cookies names are prefixed
with "COOKIE_" before they are stored (this avoids accidental
corruption of local variables) To revert to the original behaviour,
define the property "CookieManager.name.prefix= " (one or more
spaces). If enabled, the value of a cookie with the name TEST can be
referred to as ${COOKIE_TEST}.
You can find these setting under JmeterFolder/bin/jmeter.properties file.
For more information:-
Cookie Manager
Kindly check if this helps.
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
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?
Is there a way to remove the p_auth in the POST header, but still having it in the body? I still required the authentication check, therefore disabling it is not the option. Thanks
I know that this is an old question but there is no answer yet. You should enable friendly url mapping in Liferay. This involves creating a xml config file describing the url patterns and routes. You can find some information on it here.
Once it is enabled you can specify the p_auth parameter to be hidden from the url.