• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

XF 1.2 Forbidden You don't have permission to access /admin.php on this server.

Jeremy

Well-known member
#6
Your host would be able to help, since the error comes directly from the server.

Are you able to access the rest of XenForo?
 

Liam W

Well-known member
#8
Check the apache error log. If it's a cPanel server, go to the error log page in your cPanel.

Look for the one near the top with your IP, and admin.php in. It'll tell you why a 403 was sent.

Liam
 

Brogan

XenForo moderator
Staff member
#9
This could be due to mod_security.

Contact your host and they should be able to identify the rule and white list it on your site.
 

Liam W

Well-known member
#10
This could be due to mod_security.

Contact your host and they should be able to identify the rule and white list it on your site.
I was thinking that, I just wasn't sure if it produced a 403 error or not.

@Jagger433 it probably is mod_security, if only some parts of the admincp are being blocked with a 403 error. You should ask your host to disable mod_security for your account, or disable the individual rule.

Liam
 

Brogan

XenForo moderator
Staff member
#14
For anyone else encountering this issue or pulling this thread up via search, what was the problem and the solution?
 

Sadik B

Well-known member
#16
Ran across this same problem. Was caused by mod_security as mentioned. In our case, since ours is a private community, we just disabled mod_security.
 
#17
I just discovered this thread since I am now having the same issue.
We are trying to get on a new server and parts of the admin page are getting 403 errors.

Seems like most of the admicp is accessible, however, the web requests are getting denied.
EG. the "Save" when turning a board active or de-active.

mod_security was temporarily disabled and everything worked fine.

I am not sure I like the idea of leaving it off so researching the mod_security rule to allow these requests to succeed.

Glad I found this thread, any tips on how to configure mod_security is appreciated.
 

Mike

XenForo developer
Staff member
#18
Mod_security should log (or be able to log) the specific rules that are being violated. Once you determine that, you can disable those rules specifically.
 
#19
Mod_security should log (or be able to log) the specific rules that are being violated. Once you determine that, you can disable those rules specifically.
TY

I was able to find the reason for the rejection.
The sql injection rule triggered and rejected the request.

That brings up the question...are the mod_security rules overly aggressive or is the XF site not safe from sql injection attacks?

Here is one specific example:
From the Admin CP->Board Active

I entered the following text into "Inactive Board Message"
Sorry, we're currently performance maintenance. Please check back shortly.​

I was able to pass mod_security by simply removing the single quote from "were".

mod_security rejected that due to the following:
Code:
--3a105972-H--
Message: Access denied with code 403 (phase 2). Pattern match "(?i:(?:,.*?[)\\da-f\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98][\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98](?:[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98].*?[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]|\\Z|[^\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]+))|(?:\\Wselect.+\\W*?from)|((? ..." at ARGS:options[boardInactiveMessage]. [file "/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "209"] [id "981257"] [msg "Detects MySQL comment-/space-obfuscated injections and backtick termination"] [data "Matched Data: , we're currently performance maintenance. Please check back shortly. found within ARGS:options[boardInactiveMessage]: Sorry, we're currently performance maintenance. Please check back shortly."] [severity "CRITICAL"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"]
Action: Intercepted (phase 2)
Apache-Handler: application/x-httpd-php
Stopwatch: 1413747980585956 4320 (- - -)
Stopwatch2: 1413747980585956 4320; combined=3297, p1=249, p2=3042, p3=0, p4=0, p5=5, sr=82, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.7 (http://www.modsecurity.org/); OWASP_CRS/2.2.8.
Server: Apache/2.4.7 (Ubuntu)
Engine-Mode: "ENABLED"
In another example, I tried to create a new thread.
mod_security also rejected this due to a "Tautology" detected.

Code:
--6d36a628-H--
Message: Access denied with code 403 (phase 2). Pattern match "(?i:([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*?)\\b([\\d\\w]++)
    ([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*?)(?:(?:=|<=>|r?like|sounds\\s+like|regexp)
    ([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*?)\\2\\b|(?:!=|<=|>=|<>|<|>|\\^|is\\s+not ..." at ARGS:message_html.
    [file "/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
    [line "77"] [id "950901"] [rev "2"] [msg "SQL Injection Attack: SQL Tautology Detected."]
    [data "Matched Data: p>hello found within ARGS:message_html: <p>hello, test</p>"]
    [severity "CRITICAL"] [ver "OWASP_CRS/2.2.8"] [maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"]
    [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
Action: Intercepted (phase 2)
Apache-Handler: application/x-httpd-php
Stopwatch: 1413767400971405 2872 (- - -)
Stopwatch2: 1413767400971405 2872; combined=1850, p1=276, p2=1567, p3=0, p4=0, p5=6, sr=88, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.7 (http://www.modsecurity.org/); OWASP_CRS/2.2.8.
Server: Apache/2.4.7 (Ubuntu)
Engine-Mode: "ENABLED"
I would have expected the entire site to be projected against SQL Injection.

Given how awesome the XF product is; I'm a little confused as to why that would be the reason mod_security to reject the request.
 

Mike

XenForo developer
Staff member
#20
That brings up the question...are the mod_security rules overly aggressive or is the XF site not safe from sql injection attacks?
XF doesn't even get run when mod_security triggers; mod_security has no way of knowing whether or not the input would be a problem so it just blacklists anything that might be problematic.