Re: [users@httpd] silent redirecting

[Jonathon Koyle]

ProxyPass is one way to do what you described. Rather than a redirect it
connects to example.com and passes traffic back and forth.

On Mon, Feb 8, 2021, 19:43 Edwardo Garcia  wrote:

> Halo,
>
> I have situation where we have, let us say  alpha.example.com
> bravo.example.com, we want to redirect them and example.com   to
> zulu.example.com _but_for that and every page under, they
> retain address bar of their original request hostname
>
> ex: alpha.example.com   click on subheading for
> alpha.example.com/page2/foobar.html  both appears as this to user,
> even though it would be actual  zulu.example.com and
> zulu.example.com/page2/foobar.html
>
> This is doable with apache?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

[users@httpd] silent redirecting

[Edwardo Garcia]

Halo,

I have situation where we have, let us say  alpha.example.com
bravo.example.com, we want to redirect them and example.com   to
zulu.example.com _but_for that and every page under, they
retain address bar of their original request hostname

ex: alpha.example.com   click on subheading for
alpha.example.com/page2/foobar.html  both appears as this to user,
even though it would be actual  zulu.example.com and
zulu.example.com/page2/foobar.html

This is doable with apache?

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

RE: [users@httpd] Which parameters must be set to solve these Vulnerabilities? [EXT]

[James Smith]

Without knowing what your website is we can’t really see what is wrong. Have 
you used chrome (or whatever browser you are using) developer’s tools to see 
what is blocked by your content security policy (CSP)

From: Nick Folino 
Sent: 08 February 2021 17:30
To: users@httpd.apache.org
Subject: Re: [users@httpd] Which parameters must be set to solve these 
Vulnerabilities? [EXT]

What a great site!  It consolidates weak servers for hackers to find easier.

On Mon, Feb 8, 2021 at 11:00 AM Jason Long 
mailto:hack3r...@yahoo.com.invalid>> wrote:
Thank you for your useful information.
I checked my server with "https://securityheaders.com/ 
[securityheaders.com]"
 and result is:
https://i.postimg.cc/SsBBtRsT/Header.png 
[i.postimg.cc]

To solve the Content Security Policy, I added below line to "httpd.conf":
Header set Content-Security-Policy "default-src 'self';"

But after it my web site style messed up! Why?
How about "Permissions-Policy" ?






On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti 
mailto:d...@tuxweb.it>> wrote:





> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:


There are many ways of solving those vulnerabilities. Most of them can be fixed 
patching your
applications.

As rule of thumb, your application should:
- not use frames or iframes at all
- use only HTTPS everywhere, always redirect HTTP to HTTPS
- disable anything you don't need (eg mod_perl, mod_php, etc)
- enable Strict-Transport-Security to force all traffic to HTTPS with no 
failback to HTTP
- don't use cookies if possible, or setup your cookies with those attributes: 
secure; HostOnly; HttpOnly;
SameSite=Lax
- CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be 
setted directly by your application and not from apache, if possible

Please consider that enabling one or more countermeasures via configuration 
file in httpd could make your applications stop working properly if they are 
not designed accordingly! Please double check any of them and test them in your 
staging environment before setting them live for production.

Also you should be well confident in all of them before running live, or 
strange things will happen to your applications and your live debug will be 
difficult.

-
To unsubscribe, e-mail: 
users-unsubscr...@httpd.apache.org
For additional commands, e-mail: 
users-h...@httpd.apache.org



-
To unsubscribe, e-mail: 
users-unsubscr...@httpd.apache.org
For additional commands, e-mail: 
users-h...@httpd.apache.org



-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.

Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities?

[Nick Folino]

What a great site!  It consolidates weak servers for hackers to find easier.

On Mon, Feb 8, 2021 at 11:00 AM Jason Long 
wrote:

> Thank you for your useful information.
> I checked my server with "https://securityheaders.com/; and result is:
> https://i.postimg.cc/SsBBtRsT/Header.png
>
> To solve the Content Security Policy, I added below line to "httpd.conf":
> Header set Content-Security-Policy "default-src 'self';"
>
> But after it my web site style messed up! Why?
> How about "Permissions-Policy" ?
>
>
>
>
>
>
> On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti <
> d...@tuxweb.it> wrote:
>
>
>
>
>
> > Hello,
> > I scanned my Apache web server and below Vulnerabilities discovered:
>
>
> There are many ways of solving those vulnerabilities. Most of them can be
> fixed patching your
> applications.
>
> As rule of thumb, your application should:
> - not use frames or iframes at all
> - use only HTTPS everywhere, always redirect HTTP to HTTPS
> - disable anything you don't need (eg mod_perl, mod_php, etc)
> - enable Strict-Transport-Security to force all traffic to HTTPS with no
> failback to HTTP
> - don't use cookies if possible, or setup your cookies with those
> attributes: secure; HostOnly; HttpOnly;
> SameSite=Lax
> - CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be
> setted directly by your application and not from apache, if possible
>
> Please consider that enabling one or more countermeasures via
> configuration file in httpd could make your applications stop working
> properly if they are not designed accordingly! Please double check any of
> them and test them in your staging environment before setting them live for
> production.
>
> Also you should be well confident in all of them before running live, or
> strange things will happen to your applications and your live debug will be
> difficult.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

[users@httpd] Details on writing an authentication module?

[Mark H. Wood]

I found some help on writing modules in general, but nothing on
requirements specific to authentication modules.  Would someone please
point me in the right direction.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: [users@httpd] RE: Apache authorization using require dbd-group from SQL Server database

[Yann Ylavic]

Thanks Kyle.

Since this fix resulted in two 2.4 changes actually, it's possibly
worth mentioning them to the redhat team, that could help them:
- http://svn.apache.org/r1701404
- http://svn.apache.org/r1701405

Regards;
Yann.

On Mon, Feb 8, 2021 at 5:27 PM Kyle Hansen  wrote:
>
> Good suggestion.  Done here (https://bugs.centos.org/view.php?id=18053) for 
> anyone that may be interested.
>
> -Original Message-
> From: Yann Ylavic 
> Sent: Saturday, February 6, 2021 7:31 AM
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] RE: Apache authorization using require dbd-group 
> from SQL Server database
>
> Hi Kyle,
>
> On Sat, Feb 6, 2021 at 12:21 AM Kyle Hansen  
> wrote:
> >
> > After a lot of work, I was able to solve this myself.  I updated the 
> > previously linked Stack Overflow link with the solution, but am copying it 
> > here for completeness.
>
> Thanks for the feedback.
>
> >
> > My Apache Version was 2.4.6 but the most recent RHEL Version,
> > httpd-2.4.6-97.el7.centos I believe. Looking at the Change Log for
> > apache 2.4 (https://www.apachelounge.com/Changelog-2.4.html) most of
> > the mod_authz_dbd changes were included in the CentOS version except
> > for the one integrated in Apache 2.4.17 entitled
> >
> > *) mod_authz_dbd: Avoid a crash when lacking correct DB access permissions.
> >PR 57868. [Jose Kahan < jose w3.org>, Yann Ylavic]
> []
> > Unfortunately, my Apache now doesn't have the benefits of RHEL if I go
> > this route
>
> You may want to reach out with the RHEL/centos team to report this bug and 
> upstream fix to possibly have it included in their httpd-2.4.6-next version.
>
> Regards;
> Yann.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

RE: [users@httpd] Which parameters must be set to solve these Vulnerabilities? [EXT]

[James Smith]

-Original Message-
From: Eric Covener  
Sent: 08 February 2021 13:13
To: users@httpd.apache.org
Subject: Re: [users@httpd] Which parameters must be set to solve these 
Vulnerabilities? [EXT]

On Mon, Feb 8, 2021 at 6:24 AM Jason Long  wrote:
>
> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:
>
> 1- Content Security Policy (CSP) Header Not Set
Read up about these and set an appropriate header
> 2- HTTP to HTTPS Insecure Transition in Form Post
Make sure you don't actively have an http:// request use HSTS headers
> 3- Reverse Tabnabbing
Set rel=noopener 
> 4- Source Code Disclosure - PHP
Make sure you make all PHP code be executed by php handler and make sure you 
have got full PHP tags ( 5- Source Code Disclosure - Perl
Don't put perl in your htdocs directory - keep it outside
Don't log errors to browser
> 6- Sub Resource Integrity Attribute Missing
See 10
> 7- Absence of Anti-CSRF Tokens
Look at form code - you need to set a cookie and a hidden field in the form
> 8- Cookie No HttpOnly Flag
Add this to your cookie creation statement (note there may be some cases where 
it is impossible to set this - if you want the client to see this!)
> 9- Cookie Without SameSite Attribute
Add this to your cookie creation statement (note there may be some cases where 
it is impossible to set this - if you want the client to see this!) and specify 
exactly which sub-domain gets the cookie not .mydomain.com but 
server.mydomain.com
> 10- Cross-Domain JavaScript Source File Inclusion
Don't if you do - look at CSP and set "integrity" or only allow from certain 
sites...
> 11- Incomplete or No Cache-control and Pragma HTTP Header Set
Again look this up - there may be reasons why this isn't set - e.g. 
> 12- Insufficient Site Isolation Against Spectre Vulnerability
Look at CORS
> 13- Strict-Transport-Security Header Not Set
Just set it again read docs...
>
> I'm thankful if anyone tell me which parameters and headers must be set and 
> enable in the Apache configuration.

I suggest searching the web for existing explanations/resources. You will also 
need to address most of these with an understanding of your content.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org




-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

RE: [users@httpd] RE: Apache authorization using require dbd-group from SQL Server database

[Kyle Hansen]

Good suggestion.  Done here (https://bugs.centos.org/view.php?id=18053) for 
anyone that may be interested.

-Original Message-
From: Yann Ylavic  
Sent: Saturday, February 6, 2021 7:31 AM
To: users@httpd.apache.org
Subject: Re: [users@httpd] RE: Apache authorization using require dbd-group 
from SQL Server database

Hi Kyle,

On Sat, Feb 6, 2021 at 12:21 AM Kyle Hansen  wrote:
>
> After a lot of work, I was able to solve this myself.  I updated the 
> previously linked Stack Overflow link with the solution, but am copying it 
> here for completeness.

Thanks for the feedback.

>
> My Apache Version was 2.4.6 but the most recent RHEL Version, 
> httpd-2.4.6-97.el7.centos I believe. Looking at the Change Log for 
> apache 2.4 (https://www.apachelounge.com/Changelog-2.4.html) most of 
> the mod_authz_dbd changes were included in the CentOS version except 
> for the one integrated in Apache 2.4.17 entitled
>
> *) mod_authz_dbd: Avoid a crash when lacking correct DB access permissions.
>PR 57868. [Jose Kahan < jose w3.org>, Yann Ylavic]
[]
> Unfortunately, my Apache now doesn't have the benefits of RHEL if I go 
> this route

You may want to reach out with the RHEL/centos team to report this bug and 
upstream fix to possibly have it included in their httpd-2.4.6-next version.

Regards;
Yann.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities?

[Jason Long]

Thank you for your useful information.
I checked my server with "https://securityheaders.com/; and result is:
https://i.postimg.cc/SsBBtRsT/Header.png

To solve the Content Security Policy, I added below line to "httpd.conf":
Header set Content-Security-Policy "default-src 'self';"

But after it my web site style messed up! Why?
How about "Permissions-Policy" ?






On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti 
 wrote: 





> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:


There are many ways of solving those vulnerabilities. Most of them can be fixed 
patching your
applications.

As rule of thumb, your application should:
- not use frames or iframes at all
- use only HTTPS everywhere, always redirect HTTP to HTTPS
- disable anything you don't need (eg mod_perl, mod_php, etc)
- enable Strict-Transport-Security to force all traffic to HTTPS with no 
failback to HTTP
- don't use cookies if possible, or setup your cookies with those attributes: 
secure; HostOnly; HttpOnly;
SameSite=Lax
- CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be 
setted directly by your application and not from apache, if possible

Please consider that enabling one or more countermeasures via configuration 
file in httpd could make your applications stop working properly if they are 
not designed accordingly! Please double check any of them and test them in your 
staging environment before setting them live for production.

Also you should be well confident in all of them before running live, or 
strange things will happen to your applications and your live debug will be 
difficult.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities?

[Dino Ciuffetti]

> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:

There are many ways of solving those vulnerabilities. Most of them can be fixed 
patching your
applications.

As rule of thumb, your application should:
- not use frames or iframes at all
- use only HTTPS everywhere, always redirect HTTP to HTTPS
- disable anything you don't need (eg mod_perl, mod_php, etc)
- enable Strict-Transport-Security to force all traffic to HTTPS with no 
failback to HTTP
- don't use cookies if possible, or setup your cookies with those attributes: 
secure; HostOnly; HttpOnly;
SameSite=Lax
- CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be 
setted directly by your application and not from apache, if possible

Please consider that enabling one or more countermeasures via configuration 
file in httpd could make your applications stop working properly if they are 
not designed accordingly! Please double check any of them and test them in your 
staging environment before setting them live for production.

Also you should be well confident in all of them before running live, or 
strange things will happen to your applications and your live debug will be 
difficult.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities?

[Eric Covener]

On Mon, Feb 8, 2021 at 6:24 AM Jason Long  wrote:
>
> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:
>
> 1- Content Security Policy (CSP) Header Not Set
> 2- HTTP to HTTPS Insecure Transition in Form Post
> 3- Reverse Tabnabbing
> 4- Source Code Disclosure - PHP
> 5- Source Code Disclosure - Perl
> 6- Sub Resource Integrity Attribute Missing
> 7- Absence of Anti-CSRF Tokens
> 8- Cookie No HttpOnly Flag
> 9- Cookie Without SameSite Attribute
> 10- Cross-Domain JavaScript Source File Inclusion
> 11- Incomplete or No Cache-control and Pragma HTTP Header Set
> 12- Insufficient Site Isolation Against Spectre Vulnerability
> 13- Strict-Transport-Security Header Not Set
>
> I'm thankful if anyone tell me which parameters and headers must be set and 
> enable in the Apache configuration.

I suggest searching the web for existing explanations/resources. You
will also need to address most of these with an understanding of your
content.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Which parameters must be set to solve these Vulnerabilities?

[Jason Long]

Hello,
I scanned my Apache web server and below Vulnerabilities discovered:

1- Content Security Policy (CSP) Header Not Set
2- HTTP to HTTPS Insecure Transition in Form Post
3- Reverse Tabnabbing
4- Source Code Disclosure - PHP
5- Source Code Disclosure - Perl
6- Sub Resource Integrity Attribute Missing
7- Absence of Anti-CSRF Tokens
8- Cookie No HttpOnly Flag
9- Cookie Without SameSite Attribute
10- Cross-Domain JavaScript Source File Inclusion
11- Incomplete or No Cache-control and Pragma HTTP Header Set
12- Insufficient Site Isolation Against Spectre Vulnerability
13- Strict-Transport-Security Header Not Set

I'm thankful if anyone tell me which parameters and headers must be set and 
enable in the Apache configuration.

Thank you.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Is it possible to exclude a directory from listing?

[Jason Long]

Hello,
Any idea?






On Friday, January 29, 2021, 04:07:30 PM GMT+3:30, Jason Long 
 wrote: 





Thank you for your reply.
The "wp-content" directory is a sub-directory of "wp" directory:
$ ls /var/www/wp/
cgi-bin                                      wp-content
error_log                                  wp-cron.php
googlee4e6cdb3b56c49dd.html  wp-includes
index.php                                         wp-links-opml.php
license.txt                                         wp-load.php
readme.html                                     wp-login.php
ssl                                 wp-mail.php
wordfence-waf.php                           wp-settings.php
wp-activate.php                                wp-signup.php
wp-admin                                          wp-statistics.log
wp-blog-header.php                          wp-trackback.php
wp-comments-post.php         xmlrpc.php
wp-config.php                zhupclient_key.1567309333.html
wp-config-sample.php                       zhupclient_key.1567317901.html


How about "AllowOverride All"? 
If I want to disable the Directory Listing for all directories then what should 
my settings be like?
If I want to disable the Directory Listing for all directories except 
"wp-includes" directory then what should my settings be like?

Thank you.





On Friday, January 22, 2021, 01:11:41 AM GMT+3:30, Antony Stone 
 wrote: 





On Thursday 21 January 2021 at 22:09:39, Jason Long wrote:

> I did:
> 
> Options -Indexes
> AllowOverride All
> Require all granted
> 
> 
> But when I browse "https://MyDomain.net/wp-content/plugins; then I can see
> the content of the plugins directory! Why?

Perhaps because "wp-content" is not the same as "wp"?

You've told us what your settings are for "/var/www/wp".

We have no idea how this relates to "https://MyDomain.net/wp-content/plugins;

Show us more of your configuration and someone might be able to help.

Oh, and by the way, why do you want "AllowOverride All"?


Antony.

-- 
Never write it in Perl if you can do it in Awk.
Never do it in Awk if sed can handle it.
Never use sed when tr can do the job.
Never invoke tr when cat is sufficient.
Avoid using cat whenever possible.

                                                  Please reply to the list;
                                                        please *don't* CC me.


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org