Failure 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 trust made by the .NET Framework whenever code from a strong named assembly is loaded and JIT-compiled. [assembly:AllowPartiallyTrustedCallersAttribute()] For 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: Field name Description $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: Operator Value == 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" { url.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 . Failure 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,. 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. 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