However, a motivated, skilled, or just plain lucky attacker may be able to find and access these pages, invoke functions, and view data.. Security by obscurity is not sufficient to prote
Trang 1Failure to Restrict URL Access
Definition:
Frequently, the only protection for a URL is that links to that page are not presented to unauthorized users However, a motivated, skilled, or just plain lucky attacker may be able to find and access these pages, invoke functions, and view data Security by obscurity is not sufficient to protect sensitive
functions and data in an application Access control checks must be performed before a request to a sensitive function is granted, which ensures that the user is authorized to access that function
Protection:
Taking the time to plan authorization by creating a matrix to map the roles and functions of the
application is a key step in achieving protection against unrestricted URL access Web applications must enforce access control on every URL and business function
It is not sufficient to put access control into the presentation layer and leave the business logic
unprotected
It is also not sufficient to check once during the process to ensure the user is authorized, and then not check again on subsequent steps Otherwise, an attacker can simply skip the step where authorization is checked, and forge the parameter values necessary to continue on at the next step
Enabling URL access control takes some careful planning Among the most important considerations are:
• Ensure the access control matrix is part of the business, architecture, and design of the application
• Ensure that all URLs and business functions are protected by an effective access control mechanism that verifies the user’s role and entitlements prior to any processing taking place Make sure this is done during every step of the way, not just once towards the beginning of any multi-step process
• Perform a penetration test prior to deployment or code delivery to ensure that the application cannot be misused by a motivated skilled attacker
• Do not assume that users will be unaware of special or hidden URLs or APIs Always ensure that
administrative and high privilege actions are protected
• An administrator will have a menu with an URL /admin, A non-admin user can enter the URL manually but you will not allow access
.Net Overview:
Web application contains code that requires more permissions than are granted by a particular ASP.NET trust level, the easiest option is customizing a policy file to grant the additional code access security permission to your Web application
securityPolicy>
trustLevel name="Custom" policyFile="web_yourtrust.config"/>
/securityPolicy>
We annotate any strong named assembly with AllowPartiallyTrustedCallersAttribute to support partial-trust callers This suppresses an implicit link demand for full partial-trust made by the NET Framework
whenever code from a strong named assembly is loaded and JIT-compiled
Trang 2For more information read the article
-Lighttpd has mod_access module The access module is used to deny access to files with given trailing path names You need to combine this with remoteip conditional configuration
Conditional Configuration:
$HTTP["url"] match on url If there are nested blocks, this must be the most inner block
$HTTP["remoteip"] match on the remote IP or a remote Network (Warning: doesn't work with IPv6
enabled)
<operator> is one of:
== string equal match
!= string not equal match
=~ perl style regular expression match
!~ perl style regular expression not match
Configuration:
Open your lighttpd configuration file:
# vi /etc/lighttpd/lighttpd.conf
Append the add mod_ access to list of server modules:
server.modules = ( "mod_access" )
Examples:
Block access to http://domain.com/docs/ url if IP address is NOT 192.168.1.5 and 192.168.1.6:
$HTTP["remoteip"] !~ "192.168.1.5|192.168.1.6"
$HTTP["url"] =~ "^/docs/" {
url.access-deny = ( "" ) }
}
Do not allow IP address 192.168.1.5 to access the site:
$HTTP["remoteip"] == "192.168.1.5" {
Trang 3url.access-deny = ( "" ) }
Do not allow IP address 192.168.1.5, 192.168.1.6 to access our site:
$HTTP["remoteip"] =~ "192.168.1.5|192.168.1.6" {
url.access-deny = ( "" ) }
Deny the access to www.example.org to all which are not in the 10.0.0.0/8 network :
$HTTP["host"] == "www.example.org" {
$HTTP["remoteip"] != "10.0.0.0/8" {
url.access-deny = ( "" ) }
}
Deny the access to www.example.org to all which are not in the 10.0.0.0/8 and/or 172.16.2.0/24 network:
$HTTP["host"] == "www.example.org" {
$HTTP["remoteip"] != "10.0.0.0/8, 172.16.2.0/24" {
url.access-deny = ( "" ) }
}
Allow only 200.19.1.5 and 210.45.2.7 to have access to www.example.org/admin/:
$HTTP["host"] == "www.example.org" {
$HTTP["remoteip"] !~ "^(200\.19\.1\.5|210\.45\.2\.7)$" {
$HTTP["url"] =~ "^/admin/" {
url.access-deny = ( "" ) }
}
Reference:
http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:Configuration
http://www.cyberciti.biz/tips/lighttpd-restrict-or-deny-access-by-ip-address.html