فا

‫ اخبار

صفحات: «« « ... 2 3 4 5 6 ... » »»
SQL Server Security- 7th Section- Managing Permissions with Stored Procedures
IRCAR201406222
Date: 2014-06-30
  1. Introduction
SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.
Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.
The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.
Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.
The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.
  1. Managing Permissions with Stored Procedures in SQL Server
One method of creating multiple lines of defense around your database is to implement all data access using stored procedures or user-defined functions. You revoke or deny all permissions to underlying objects, such as tables, and grant EXECUTE permissions on stored procedures. This effectively creates a security perimeter around your data and database objects.

Stored procedures have the following benefits:
  • Data logic and business rules can be encapsulated so that users can access data and objects only in ways that developers and database administrators intend.
  • Parameterized stored procedures that validate all user input can be used to thwart SQL injection attacks. If you use dynamic SQL, be sure to parameterize your commands, and never include parameter values directly into a query string.
  • Ad hoc queries and data modifications can be disallowed. This prevents users from maliciously or inadvertently destroying data or executing queries that impair performance on the server or the network.
  • Errors can be handled in procedure code without being passed directly to client applications. This prevents error messages from being returned that could aid in a probing attack. Log errors and handle them on the server.
  • Stored procedures can be written once, and accessed by many applications.
  • Client applications do not need to know anything about the underlying data structures. Stored procedure code can be changed without requiring changes in client applications as long as the changes do not affect parameter lists or returned data types.
  • Stored procedures can reduce network traffic by combining multiple operations into one procedure call.

Stored procedures take advantage of ownership chaining to provide access to data so that users do not need to have explicit permission to access database objects. An ownership chain exists when objects that access each other sequentially are owned by the same user. For example, a stored procedure can call other stored procedures, or a stored procedure can access multiple tables. If all objects in the chain of execution have the same owner, then SQL Server only checks the EXECUTE permission for the caller, not the caller's permissions on other objects. Therefore you need to grant only EXECUTE permissions on stored procedures; you can revoke or deny all permissions on the underlying tables.

Simply writing stored procedures isn't enough to adequately secure your application. You should also consider the following potential security holes.
  • Grant EXECUTE permissions on the stored procedures for database roles you want to be able to access the data.
  • Revoke or deny all permissions to the underlying tables for all roles and users in the database, including the public role. All users inherit permissions from public. Therefore denying permissions to public means that only owners and sysadmin members have access; all other users will be unable to inherit permissions from membership in other roles.
  • Do not add users or roles to the sysadmin or db_owner roles. System administrators and database owners can access all database objects.
  • Disable the guest account. This will prevent anonymous users from connecting to the database. The guest account is disabled by default in new databases.
  • Implement error handling and log errors.
  • Create parameterized stored procedures that validate all user input. Treat all user input as untrusted.
  • Avoid dynamic SQL unless absolutely necessary. Use the Transact-SQL QUOTENAME() function to delimit a string value and escape any occurrence of the delimiter in the input string.
References:
18 مرداد 1393 برچسب‌ها: مقالات
Web Browser Security Revisited (Part 3)
IRCAR201405218

Date: 2014/05/17

Introduction

In Part 1 of this series, we discussed the importance of web browser security and some security-related issues that are common to all or many of the popular browsers today. In Part 2, we talked about some specific security mechanisms that are built into Internet Explorer and how they’re implemented. This time, we’ll look at how to configure IE for best security.

Configuring Internet Explorer for best security practices

As with any browser, the first step in making IE as secure as possible is to update to the latest version. If you’re using Windows 7 or Windows 8/8.1, that means IE 11. If you’re still running XP, that means IE 8 and for Vista users, IE 9 – although if you really care about security, best practice is to upgrade your operating system to Windows 7 or 8/8.1, especially if you’re running XP, support for which will end in April 2014. Thus we’ll focus on configuring IE 11 here.

Install security updates

Regardless of the browser version, Step 2 should be installation of all available security updates for IE, and of course you need to keep it up to date as new patches come out. But it’s not just IE itself that needs to be updated. Many exploits are sneaky; they use the “back door” of browser add-ons to get in and do their dirty work. Be aware of what browser add-ons/plug-ins/extensions are installed and ensure that any updates released for them are installed, too.

Windows Update will tell you if there are IE updates that are missing, but for third party add-ons, you might need to run a browser scanning utility on individual computers or, for better efficiency in the business environment, use patch management software that checks for third party updates.

There may be add-ons installed that you don’t use or don’t need, as well. As with any software or service, best security practice is to remove or disable any unneeded add-ons. You can manage add-ons by clicking the Tools menu in IE and selecting Manage add-ons. Here you can disable those add-ons you don’t need.

You can remove some add-ons completely, although some can only be disabled.

Enable built-in security mechanisms

Recent versions of IE include many built-in security mechanisms. Depending on the version, some of these are enabled by default and some aren’t. Even for those that are, there is the possibility of users or even other admins making changes to the settings, rendering the browser less security. For best security, you’ll want to enable technologies such as SmartScreen filtering, ActiveX filtering, and tracking protection.

Here are some settings to check:

  • Ensure Protected Mode is enabled. This setting is done via a checkbox that you’ll find by clicking the Tools icon, Internet Options, and the Security tab, as shown in Figure 1. (We discussed security zones earlier in this series). IE 11 supports Enhanced Protected Mode, as we discussed earlier in this series. When Enhanced Protected Mode is running, add-ons will only work if they are compatible with Enhanced Protected Mode.



  • Many of today’s laptops and tablets and even some desktops have location services enabled, which can determine the location of the device through GPS, wi-fi, and/or LTE radio transmissions. This is handy for enabling the browser to show search results that are nearby, automatically detect the starting point in giving map directions, and so forth. However, allowing web sites to see your location information can also be a security risk. On the Privacy tab of Internet Options, you can check a box to Never allow websites to request your physical location, as shown in Figure 2.




  • Pop-ups can contain malicious code. The Privacy tab of Internet Options is also where you configure the popup blocker. By default, it’s set to Block most automatic pop-ups, but you can change the settings here to either Block all pop-ups or to Allow pop-ups from secure sites. Note that “secure” doesn’t necessarily mean “safe.” A secure site is one that uses SSL/TLS to encrypt information sent to it over the Internet. Anyone can buy an SSL certificate from a public certification authority. Sites with extended validation (EV) certificates (identified by the “green bar” in the browser window) have gone through stricter vetting to confirm the identities of the web site operators. When you block pop-ups, you can “whitelist” particular sites whose pop-ups you want to allow.
  • There are a number of security-related settings on the Advanced tab of Internet Options, as shown in Figure 3. As noted previously, this is where you can enable Enhanced Protected Mode, which is not enabled by default in IE 11 – unless you’re running Windows 8.1 and haven’t installed the November 2013 updates. Microsoft enabled EPM in Windows 8.1 by default, then disabled it via one of those updates.


The following security settings are checked by default (and should be left that way unless you have a compelling reason to change it): checking for publisher’s certificate revocation, checking for server certificate revocation, checking for signatures on downloaded programs, DOM storage enabled, integrated Windows authentication enabled, native XMLHTTP support enabled, SmartScreen Filter enabled, sending of Do Not Track requests, SSL 3.0, TLS 1.0, 1.1 and 1.2.

You can increase security by enabling some of the items that are not checked by default, but be aware that some of these settings could negatively impact the browser’s ability to access certain sites or resources. Many of the items not checked by default should stay that way for best security. Here are the ones that you might consider changing:

  • Do not save encrypted pages to disk
  • Empty Temporary Internet Files folder when browser is closed
  • Enable Strict P3P validation
  • Warn if changing between secure and not secure mode

Use Group Policy to control IE security settings

You can ensure that IE’s security-related settings on all the machines on your network are configured as you want, and keep them that way, by using Group Policy to enforce the settings. You can do this by using the administrative templates to edit registry-based policy settings. Be sure that when you install IE 11 on the machines, you do so under standard user accounts (not admin) so the users won’t be able to override the Group Policy and change the settings.

When managing IE 11 settings via Group Policy, you can use the Group Policy Management Console (GPMC), the Advanced Group Policy Management Console (AGPMC) for Software Assurance customers, or the local Group Policy Editor. You can also automate the management of Group Policy using PowerShell.

To install the GPMC on your Windows 8.1 computer, download and install the Remote Server Administration Tools (RSAT) for Windows 8.1.

To edit Group Policy, you must have Edit permission for the Group Policy Object (GPO). Domain administrators, Enterprise administrators and members of the Group Policy Creator Owners group have permission by default.

When using the local Group Policy Editor, settings for IE can be configured under Computer Configuration | Administrative Templates | Windows Components | Internet Explorer.

Under Security Features, you’ll find settings for Add-on Management, where you can configure a list of add-ons to be allowed or denied by IE, specifying that IE should Deny all add-ons unless specifically allowed in the Add-on List and a setting to Turn off Adobe Flash in IE.

Other Security Features settings include those controlling AJAX, Binary Behavior Security Restriction, Consistent MIME handling, Local Machine Lockdown Security, and more as listedin the left pane in the figure above.

Other useful policies include preventing users from resetting IE settings and preventing users from enabling or disabling add-ons.

Related Link:

Web Browser Security Revisited (Part 1)

Web Browser Security Revisited (Part 2)

Resource:

http://www.windowsecurity.com


18 مرداد 1393 برچسب‌ها: مقالات
SQL Server Security- 6th Section- Application Security Scenarios
IRCAR201406217
Date: 2014-06-16
  1. Introduction
SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.
Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.
The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.
Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.
The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.
  1. Application Security Scenarios in SQL Server
There is no single correct way to create a secure SQL Server client application. Every application is unique in its requirements, deployment environment, and user population. An application that is reasonably secure when it is initially deployed can become less secure over time. It is impossible to predict with any accuracy what threats may emerge in the future.
SQL Server, as a product, has evolved over many versions to incorporate the latest security features that enable developers to create secure database applications. However, security doesn't come in the box; it requires continual monitoring and updating.

Developers need to understand security threats, the tools provided to counter them, and how to avoid self-inflicted security holes. Security can best be thought of as a chain, where a break in any one link compromises the strength of the whole. The following list includes some common security threats that are discussed in more detail in the topics in this section.

SQL Injection is the process by which a malicious user enters Transact-SQL statements instead of valid input. If the input is passed directly to the server without being validated and if the application inadvertently executes the injected code, then the attack has the potential to damage or destroy data. You can thwart SQL Server injection attacks by using stored procedures and parameterized commands, avoiding dynamic SQL, and restricting permissions on all users.

Elevation of privilege attacks occur when a user is able to assume the privileges of a trusted account, such as an owner or administrator. Always run under least-privileged user accounts and assign only needed permissions. Avoid using administrative or owner accounts for executing code. This limits the amount of damage that can occur if an attack succeeds. When performing tasks that require additional permissions, use procedure signing or impersonation only for the duration of the task. You can sign stored procedures with certificates or use impersonation to temporarily assign permissions.

A probing attack can use error messages generated by an application to search for security vulnerabilities. Implement error handling in all procedural code to prevent SQL Server error information from being returned to the end user.

A connection string injection attack can occur when using SQL Server logins if a connection string based on user input is constructed at run time. If the connection string is not checked for valid keyword pairs, an attacker can insert extra characters, potentially accessing sensitive data or other resources on the server. Use Windows authentication wherever possible. If you must use SQL Server logins, use the SQLConnectionStringBuilder to create and validate connection strings at run time.
2.1.5. Passwords

Many attacks succeed because an intruder was able to obtain or guess a password for a privileged user. Passwords are your first line of defense against intruders, so setting strong passwords is essential to the security of your system. Create and enforce password policies for mixed mode authentication.
Always assign a strong password to the sa account, even when using Windows Authentication.
18 مرداد 1393 برچسب‌ها: مقالات
SQL Server Security- 5th Section- Data Encryption and CLR Integration Security
IRCAR201405216
Date: 2014-05-26
  1. Introduction
SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.
Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.
The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.
Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.
The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.
  1. Data Encryption in SQL Server
SQL Server provides functions to encrypt and decrypt data using a certificate, asymmetric key, or symmetric key. It manages all of these in an internal certificate store. The store uses an encryption hierarchy that secures certificates and keys at one level with the layer above it in the hierarchy. This feature area of SQL Server is called Secret Storage.
The fastest mode of encryption supported by the encryption functions is symmetric key encryption. This mode is suitable for handling large volumes of data. The symmetric keys can be encrypted by certificates, passwords or other symmetric keys.
SQL Server supports several symmetric key encryption algorithms, including DES, Triple DES, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES, and 256-bit AES. The algorithms are implemented using the Windows Crypto API.
Within the scope of a database connection, SQL Server can maintain multiple open symmetric keys. An open key is retrieved from the store and is available for decrypting data. When a piece of data is decrypted, there is no need to specify the symmetric key to use. Each encrypted value contains the key identifier (key GUID) of the key used to encrypt it. The engine matches the encrypted byte stream to an open symmetric key, if the correct key has been decrypted and is open. This key is then used to perform decryption and return the data. If the correct key is not open, NULL is returned.
For an example that shows how to work with encrypted data in a database, see How to: Encrypt a Column of Data in SQL Server Books Online.
  1. CLR Integration Security in SQL Server
Microsoft SQL Server provides the integration of the common language runtime (CLR) component of the .NET Framework. CLR integration allows you to write stored procedures, triggers, user-defined types, user-defined functions, user-defined aggregates, and streaming table-valued functions, using any .NET Framework language, such as Microsoft Visual Basic .NET or Microsoft Visual C#.
The CLR supports a security model called code access security (CAS) for managed code. In this model, permissions are granted to assemblies based on evidence supplied by the code in metadata. SQL Server integrates the user-based security model of SQL Server with the code access-based security model of the CLR.
References:
http://msdn.microsoft.com/
18 مرداد 1393 برچسب‌ها: مقالات
SQL Server Security- 4th Section- Authorization and Permissions
IRCAR201405215
Date: 2014-05-12
  1. Introduction
SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.
Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.
The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.
Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.
The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.
  1. Authorization and Permissions in SQL Server
When you create database objects, you must explicitly grant permissions to make them accessible to users. Every securable object has permissions that can be granted to a principal using permission statements.

Developing an application using a least-privileged user account (LUA) approach is an important part of a defensive, in-depth strategy for countering security threats. The LUA approach ensures that users follow the principle of least privilege and always log on with limited user accounts. Administrative tasks are broken out using fixed server roles, and the use of the sysadmin fixed server role is severely restricted.
Always follow the principle of least privilege when granting permissions to database users. Grant the minimum permissions necessary to a user or role to accomplish a given task.
Security Note
Developing and testing an application using the LUA approach adds a degree of difficulty to the development process. It is easier to create objects and write code while logged on as a system administrator or database owner than it is using a LUA account. However, developing applications using a highly privileged account can obfuscate the impact of reduced functionality when least privileged users attempt to run an application that requires elevated permissions in order to function correctly. Granting excessive permissions to users in order to reacquire lost functionality can leave your application vulnerable to attack. Designing, developing and testing your application logged on with a LUA account enforces a disciplined approach to security planning that eliminates unpleasant surprises and the temptation to grant elevated privileges as a quick fix. You can use a SQL Server login for testing even if your application is intended to deploy using Windows authentication.

Granting permissions to roles rather than to users simplifies security administration. Permission sets that are assigned to roles are inherited by all members of the role. It is easier to add or remove users from a role than it is to recreate separate permission sets for individual users. Roles can be nested; however, too many levels of nesting can degrade performance. You can also add users to fixed database roles to simplify assigning permissions.
You can grant permissions at the schema level. Users automatically inherit permissions on all new objects created in the schema; you do not need to grant permissions as new objects are created.

Encapsulating data access through modules such as stored procedures and user-defined functions provides an additional layer of protection around your application. You can prevent users from directly interacting with database objects by granting permissions only to stored procedures or functions while denying permissions to underlying objects such as tables. SQL Server achieves this by ownership chaining.

The three Transact-SQL permission statements are described in the following table.
Permission Statement
Description
GRANT
Grants a permission.
REVOKE
Revokes a permission. This is the default state of a new object. A permission revoked from a user or role can still be inherited from other groups or roles to which the principal is assigned.
DENY
DENY revokes a permission so that it cannot be inherited. DENY takes precedence over all permissions, except DENY does not apply to object owners or members of sysadmin. If you DENY permissions on an object to the public role it is denied to all users and roles except for object owners and sysadmin members.
  • The GRANT statement can assign permissions to a group or role that can be inherited by database users. However, the DENY statement takes precedence over all other permission statements. Therefore, a user who has been denied a permission cannot inherit it from another role.
Note
Members of the sysadmin fixed server role and object owners cannot be denied permissions.

SQL Server ensures that only principals that have been granted permission can access objects. When multiple database objects access each other, the sequence is known as a chain. When SQL Server is traversing the links in the chain, it evaluates permissions differently than it would if it were accessing each item separately. When an object is accessed through a chain, SQL Server first compares the object's owner to the owner of the calling object (the previous link in the chain). If both objects have the same owner, permissions on the referenced object are not checked. Whenever an object accesses another object that has a different owner, the ownership chain is broken and SQL Server must check the caller's security context.

Suppose that a user is granted execute permissions on a stored procedure that selects data from a table. If the stored procedure and the table have the same owner, the user doesn't need to be granted any permissions on the table and can even be denied permissions. However, if the stored procedure and the table have different owners, SQL Server must check the user's permissions on the table before allowing access to the data.
Note
Ownership chaining does not apply in the case of dynamic SQL statements. To call a procedure that executes an SQL statement, the caller must be granted permissions on the underlying tables, leaving your application vulnerable to SQL Injection attack. SQL Server provides new mechanisms, such as impersonation and signing modules with certificates, that do not require granting permissions on the underlying tables. These can also be used with CLR stored procedures.

References:
http://msdn.microsoft.com/
18 مرداد 1393 برچسب‌ها: مقالات
Small Office/Home Office Router Security – Part 2
IRCAR201405213
Date: 2014-05-03
· Disable UPnP: Universal Plug and Play (UPnP) is a handy feature allowing networked devices to seamlessly discover and establish communication with each other on the network. Though the UPnP feature eases initial network configuration, it is also a security hazard. For example, malware within your network could use UPnP to open a hole in your router firewall to let intruders in. Therefore, disable UPnP when not needed.
· Upgrade firmware: Just like software on your computers, the router firmware (the software that operates it) must have current updates and patches. Many of the updates address security vulnerabilities that could affect the network.
· Use static IP addresses or limit DHCP reserved addresses: Most home routers are configured as Dynamic Host Configuration Protocol (DHCP) servers. DHCP makes configuration of client devices easy by automatically configuring their network settings (IP address, gateway address, DNS info, etc.). However, this also allows unauthorized users to obtain an IP address on your network. Disabling DHCP and configuring clients manually is the most secure option, but it may be impractical depending on the size of your network and support staff. If using DHCP, limit the number of IP addresses in the DHCP pool. It may limit the number of users, potentially including unauthorized users, that can connect to your network.
· Disable remote management: Disable this to keep intruders from establishing a connection with the router and its configuration through the wide area network (WAN) interface.
· Disable remote upgrade: This feature, if available, allows the router to listen on the WAN interface for TFTP traffic that could potentially compromise the router firmware. Therefore, it should be disabled.
· Disable DMZ: The router's demilitarized zone (DMZ) creates a segregated network exposed to the internet, used for hosts that require internet access (web servers, etc.). Disable this feature if not needed. Users or administrators sometimes enable it for troubleshooting reasons and then forget to deactivate it, exposing any system inadvertently placed there. A firewall is recommended if this feature is used.
· Disable unnecessary services: As with any computer system, disable all unnecessary services in order to reduce the router’s exposure.
· Disable ping response: The ping response setting is usually disabled by default. With this feature enabled, reconnaissance on the router becomes easier then when it is disabled. It allows your router to respond to ping commands issued from the internet, and it potentially exposes your network to intruders. Although disabling this feature will not shield you from discovery, it will at least increase the difficulty of discovery. Verify that the service is disabled.
· Enable router firewall: Most home routers include an internal firewall feature. Ensure this feature is activated and carefully configured to allow only authorized users and services access to the network. Activate stateful packet inspection (SPI) on your firewall if it is an available function. SPI extends firewall capability by inspecting packets to distinguish legitimate traffic from unsolicited traffic. Another feature offered by many home routers is the creation of whitelists or blacklists to allow or disallow a list of websites, services, ports, etc. Take advantage of this feature if it is available. Note that the firewall built in to the router does not prevent wireless users within range of your wireless network from connecting to it.
· Logging: Enable router logging and periodically review the logs for important information regarding intrusions, probes, attacks, etc.
· Monitor the wireless traffic: Monitor the wireless traffic to identify any unauthorized use of your network by performing routine log reviews of the devices that have accessed the router. If an unknown device is identified, then a firewall or MAC filtering rule can be applied on the router. For further information regarding how to apply these rules, see the literature provided by the manufacturer or the manufacturer’s site.
· Administrator workstations: Verify that any administrator workstation used to manage the router is on a trusted segment of the network to mitigate outsiders sniffing the management data and collecting information about your network.
· Don’t use the default IP ranges: Predictable addresses make CSRF attacks easier. Rather than 192.168.1.1, consider something else which is not commonly used. This is a simple but effective technique for decreasing the likelihood of a successful CSRF attack.
· Disable bridging and use network address translation (NAT): Home routers separate the internal network from the internet using network address translation (NAT). NAT provides private IP addresses for all the devices on your network. It is not directly accessible from the internet, nor can discovery of the network’s internal addresses be accomplished easily. The IP address of the external interface of the router conceals the devices on your network that are behind it. This adds an additional layer of security.
· Don’t forget to log out after configuring the router: Several of the routers will not automatically log out when not in use. This can result in a situation where the web browser used to configure the router remains authenticated, opening the door for CSRF attacks. Although some CSRF attacks can be successful without authentication, this simple step will thwart traditional CSRF attacks which rely upon that authenticated browser session.
· Some routers include a feature that allows them to act as a bridge between two networks. This feature can be used to connect segments or devices on the same intranet to the internet using a routers routable IP address. Disable this feature if not required, to further limit the attack surface of the router.
Keep in mind, this is only a list of suggested steps that can potentially help secure your small office or home router. Employing some of these suggested steps may not be feasible in your network or your environment.
Related Link:
Small Office/Home Office Router Security – Part 1
Reference:
www. US-CERT.gov/
18 مرداد 1393 برچسب‌ها: مقالات
Web Browser Security Revisited (Part 2)
IRCAR201405214

Date: 2014/05/7

Introduction

In Part 1 of this series, we discussed the importance of web browser security and some security-related issues that are common to all or many of the popular browsers today. In subsequent installments, we’re going to look at each of those browsers individually and discuss the specific security mechanisms that are built into each and how they’re implemented, and talk about some best configuration practices to make each as secure as possible.

Internet Explorer Security

Internet Explorer has been included with the Windows operating system since Windows 95 (first as part of the Plus! package), and up until Windows 7/IE 8 was an integral part of the operating system that couldn’t be removed. Unfortunately, IE garnered a reputation for security vulnerabilities due to some high profile exploits. As the browser with the most widespread usage, it is naturally the target of more hackers and attackers who want to get the most “bang for the buck.”

Much of Internet Explorer’s bad reputation is based on the past, before Microsoft started putting a high priority on security. IE 6, in particular, is well known to have serious security flaws and a couple of years ago, Microsoft launched a campaign to encourage users to upgrade from the browser that some are, nonetheless, still running on Windows XP. The good news is that the market share of those using IE 6 is now (as of October 2013) under 5 percent, according to Net Applications statistics.

However, there have been some high profile incidents where more recent browser versions were implicated, too. In early 2010, the German, Australian and French governments went so far as to recommend their citizens switch to a different browser after a major attack on Google and other companies that exploited a security flaw in IE 6, 7, and 8. Germany issued the same warning again in September of 2012, in the wake of an outbreak of the Poison Ivy Trojan that also exploits a vulnerability in IE.

Almost every month, Patch Tuesday sees Microsoft patching another vulnerability in IE. Just last September 2013, a zero day vulnerability in all supported versions of IE that, according to Microsoft, affected up to 70 percent of business users was being actively exploited “in the wild” and October’s monthly security update slate included a cumulative update for IE that addressed 10 separate vulnerabilities, including two of the zero day variety.

Despite these and other incidents, because it comes with Windows and doesn’t require downloading and installing another piece of software, IE has always held a large portion of the market share, and probably always will.

Note:

You may see widely varying statistics from different sources, due to differences in methodology regarding how the data is collected and reported. Some limit the geographic area of collection. Some collect data from more web sites than others. Some use surveys or information from regional ISPs.

On the other hand, as mentioned in Part 1, some recent studies have found that IE is better at blocking malicious software than any of the other major browsers. More recent tests indicate that both IE and Chrome are far superior to rivals Firefox and Safari when it comes to malware protection.

In any event, usage statistics prove that a majority of web users think IE is “secure enough.” And Microsoft has poured a ton of time, effort and money into improving IE’s security over the years. The very latest version is IE 11, which comes in the Windows 8.1 update that was released in final form just a few days prior to the writing of this article. Prior to that release, Microsoft hosted a reward program, inviting hackers and researchers to find security vulnerabilities in the preview version.

Beginning with IE 7 in 2006, Microsoft built in a security mechanism called Protected Mode, which is enabled by default for Internet browsing. It was designed to run IE with greatly restricted privileges and warn users when a website they were visiting attempted to run software programs that would have access to your computer outside of IE. This was a great security improvement but the problem was that Protected Mode only worked when the browser was running on Vista or above; it didn’t work in XP even if you installed the IE 7 browser, because it depended on User Account Control (UAC). Since Vista was not popular, most users and companies stayed with XP and didn’t benefit from Protected Mode.

IE 8 also brought domain highlighting, to show the real domain being visited so it would be more difficult for users to be tricked by phishing sites. It introduced the SmartScreen Filter, another anti-phishing mechanism that analyzes web pages for suspicious characteristics and checks them against a list of known phishing sites, as well as checking downloaded files. There is also a cross-site scripting filter to prevent web-based applications from gathering data from a user.

The Add-on Manager makes it easy for users to enable and disable browser add-ons (plug-ins) and get rid of ActiveX controls that aren’t needed. The InPrivate Browsing and InPrivate Filtering features also came in IE 8, to help prevent the browser from saving sensitive.

IE 9 improved on these features, including application reputation as part of the SmartScreen Filter and supports DEP/NX, ASLR and SEHOP, all of which are memory protection mechanisms. Data Execution Prevention (DEP) can prevent exploits that store executable instructions in areas of memory that should be for data, by using a buffer overflow (NX refers to the Never Execute bit that segregates areas of memory). Address Space Layout Randomization (ASLR) also protects against buffer overflow attacks by preventing attackers from accessing particular functions in memory.SEHOP (Structured Exception Handler Overwrite Protection) validates the integrity of the exception handling chain to prevent structured exception handling from being exploited.

It’s important to note that IE 9 is not available for Windows XP.

IE 10 and 11 have incorporated some new security features that include:

· Enhanced Protected Mode

· ForceASLR

· HTML5 Sandbox Attribute

Enhanced Protected Mode takes the Protected Mode feature a step further, to limit the browser so that it only has read/write access when that’s absolutely required. Manager processes now always run as 64 bit processes if you’re running a 64 bit version of Windows, which improves security. Content processes also run in 64 bit processes in the modern UI version of IE, but on the desktop run as 32 bit processes by default to maintain compatibility with add-ons. You can enable Enhanced Protected Mode in the desktop version from the Options | Advanced tab, making it more secure. When running on Windows 8, Enhanced Protected Mode also runs the Content Process in AppContainer, which is a new feature for isolating processes.

ForceASLR is an enhancement to the ASLR that was introduced in IE 7, which now randomizes the locations of all modules that the browser loads into memory. This is integrated into the Windows 8 kernel and when you install IE 10 on Windows 7, it updates that operating system to support it as well.

The sandbox attribute is new in HTML5 and it is supported by IE 10 and above. When the attribute is applied, sandboxed content is restricted in a number of ways. Plug-ins are disabled, so no ActiveX, Flash, or Silverlight content will run. Forms and JavaScript are also disabled. Anchor tags that link to different browsing contexts don’t work, and content isn’t allowed to read cookie information.

In addition, the “modern UI” version of IE 10 has limited Flash capability, allowing only “whitelisted” web sites that have been preapproved by Microsoft to run Flash content, since Flash is often targeted by attackers. IE 11 doesn’t add any major security upgrades. It does add support for WebCryptoAPI (for IE 11 on Windows 8.1).

It’s also interesting to note that IE 11 will also support WebGL. This is interesting because of Microsoft’s previous stance; in 2011 the company published a paper positing that WebGL (which is a 3D graphics API) is a security risk. That paper was, however, careful to note that they did not support WebGL “in its current form,” so those who are saying they had previously sworn to never support it are incorrect. In fact, Microsoft rep Dean Hachamovitch noted that the WebGL technology of today is different; it now includes a technology called CORS that prevents the type of attacks Microsoft was previously concerned about. The IE 11 team also built in mechanisms to screen WebGL content for suspicious activity patterns.

Related Link:

Web Browser Security Revisited (Part 1)

Web Browser Security Revisited (Part 1)

Number: IRCAR201405214

Date: 2014/05/7

Introduction

In Part 1 of this series, we discussed the importance of web browser security and some security-related issues that are common to all or many of the popular browsers today. In subsequent installments, we’re going to look at each of those browsers individually and discuss the specific security mechanisms that are built into each and how they’re implemented, and talk about some best configuration practices to make each as secure as possible.

Internet Explorer Security

Internet Explorer has been included with the Windows operating system since Windows 95 (first as part of the Plus! package), and up until Windows 7/IE 8 was an integral part of the operating system that couldn’t be removed. Unfortunately, IE garnered a reputation for security vulnerabilities due to some high profile exploits. As the browser with the most widespread usage, it is naturally the target of more hackers and attackers who want to get the most “bang for the buck.”

Much of Internet Explorer’s bad reputation is based on the past, before Microsoft started putting a high priority on security. IE 6, in particular, is well known to have serious security flaws and a couple of years ago, Microsoft launched a campaign to encourage users to upgrade from the browser that some are, nonetheless, still running on Windows XP. The good news is that the market share of those using IE 6 is now (as of October 2013) under 5 percent, according to Net Applications statistics.

However, there have been some high profile incidents where more recent browser versions were implicated, too. In early 2010, the German, Australian and French governments went so far as to recommend their citizens switch to a different browser after a major attack on Google and other companies that exploited a security flaw in IE 6, 7, and 8. Germany issued the same warning again in September of 2012, in the wake of an outbreak of the Poison Ivy Trojan that also exploits a vulnerability in IE.

Almost every month, Patch Tuesday sees Microsoft patching another vulnerability in IE. Just last September 2013, a zero day vulnerability in all supported versions of IE that, according to Microsoft, affected up to 70 percent of business users was being actively exploited “in the wild” and October’s monthly security update slate included a cumulative update for IE that addressed 10 separate vulnerabilities, including two of the zero day variety.

Despite these and other incidents, because it comes with Windows and doesn’t require downloading and installing another piece of software, IE has always held a large portion of the market share, and probably always will.

Note:

You may see widely varying statistics from different sources, due to differences in methodology regarding how the data is collected and reported. Some limit the geographic area of collection. Some collect data from more web sites than others. Some use surveys or information from regional ISPs.

On the other hand, as mentioned in Part 1, some recent studies have found that IE is better at blocking malicious software than any of the other major browsers. More recent tests indicate that both IE and Chrome are far superior to rivals Firefox and Safari when it comes to malware protection.

In any event, usage statistics prove that a majority of web users think IE is “secure enough.” And Microsoft has poured a ton of time, effort and money into improving IE’s security over the years. The very latest version is IE 11, which comes in the Windows 8.1 update that was released in final form just a few days prior to the writing of this article. Prior to that release, Microsoft hosted a reward program, inviting hackers and researchers to find security vulnerabilities in the preview version.

Beginning with IE 7 in 2006, Microsoft built in a security mechanism called Protected Mode, which is enabled by default for Internet browsing. It was designed to run IE with greatly restricted privileges and warn users when a website they were visiting attempted to run software programs that would have access to your computer outside of IE. This was a great security improvement but the problem was that Protected Mode only worked when the browser was running on Vista or above; it didn’t work in XP even if you installed the IE 7 browser, because it depended on User Account Control (UAC). Since Vista was not popular, most users and companies stayed with XP and didn’t benefit from Protected Mode.

IE 8 also brought domain highlighting, to show the real domain being visited so it would be more difficult for users to be tricked by phishing sites. It introduced the SmartScreen Filter, another anti-phishing mechanism that analyzes web pages for suspicious characteristics and checks them against a list of known phishing sites, as well as checking downloaded files. There is also a cross-site scripting filter to prevent web-based applications from gathering data from a user.

The Add-on Manager makes it easy for users to enable and disable browser add-ons (plug-ins) and get rid of ActiveX controls that aren’t needed. The InPrivate Browsing and InPrivate Filtering features also came in IE 8, to help prevent the browser from saving sensitive.

IE 9 improved on these features, including application reputation as part of the SmartScreen Filter and supports DEP/NX, ASLR and SEHOP, all of which are memory protection mechanisms. Data Execution Prevention (DEP) can prevent exploits that store executable instructions in areas of memory that should be for data, by using a buffer overflow (NX refers to the Never Execute bit that segregates areas of memory). Address Space Layout Randomization (ASLR) also protects against buffer overflow attacks by preventing attackers from accessing particular functions in memory.SEHOP (Structured Exception Handler Overwrite Protection) validates the integrity of the exception handling chain to prevent structured exception handling from being exploited.

It’s important to note that IE 9 is not available for Windows XP.

IE 10 and 11 have incorporated some new security features that include:

· Enhanced Protected Mode

· ForceASLR

· HTML5 Sandbox Attribute

Enhanced Protected Mode takes the Protected Mode feature a step further, to limit the browser so that it only has read/write access when that’s absolutely required. Manager processes now always run as 64 bit processes if you’re running a 64 bit version of Windows, which improves security. Content processes also run in 64 bit processes in the modern UI version of IE, but on the desktop run as 32 bit processes by default to maintain compatibility with add-ons. You can enable Enhanced Protected Mode in the desktop version from the Options | Advanced tab, making it more secure. When running on Windows 8, Enhanced Protected Mode also runs the Content Process in AppContainer, which is a new feature for isolating processes.

ForceASLR is an enhancement to the ASLR that was introduced in IE 7, which now randomizes the locations of all modules that the browser loads into memory. This is integrated into the Windows 8 kernel and when you install IE 10 on Windows 7, it updates that operating system to support it as well.

The sandbox attribute is new in HTML5 and it is supported by IE 10 and above. When the attribute is applied, sandboxed content is restricted in a number of ways. Plug-ins are disabled, so no ActiveX, Flash, or Silverlight content will run. Forms and JavaScript are also disabled. Anchor tags that link to different browsing contexts don’t work, and content isn’t allowed to read cookie information.

In addition, the “modern UI” version of IE 10 has limited Flash capability, allowing only “whitelisted” web sites that have been preapproved by Microsoft to run Flash content, since Flash is often targeted by attackers. IE 11 doesn’t add any major security upgrades. It does add support for WebCryptoAPI (for IE 11 on Windows 8.1).

It’s also interesting to note that IE 11 will also support WebGL. This is interesting because of Microsoft’s previous stance; in 2011 the company published a paper positing that WebGL (which is a 3D graphics API) is a security risk. That paper was, however, careful to note that they did not support WebGL “in its current form,” so those who are saying they had previously sworn to never support it are incorrect. In fact, Microsoft rep Dean Hachamovitch noted that the WebGL technology of today is different; it now includes a technology called CORS that prevents the type of attacks Microsoft was previously concerned about. The IE 11 team also built in mechanisms to screen WebGL content for suspicious activity patterns.

Related Link:

Web Browser Security Revisited (Part 1)

Resource:

18 مرداد 1393 برچسب‌ها: مقالات
DDoS Quick Guide - Part 2
IRCAR201404212
Date:17/04/2014

The core concepts of cyber security are availability, integrity, and confidentiality. Denial of Service (DoS) attacks impact the availability of information resources. The DoS is successful if it renders information resources unavailable. Success and impact differ in that impact is relative to the victim. In this section, we look at attack possibilities by OSI layer.

Attack Possibilities by OSI Layer

OSILayer

ProtocolData Unit(PDU)

LayerDescription

Protocols

ExamplesofDenialofService TechniquesatEachLevel

PotentialImpactofDoS Attack

MitigationOptionsforAttackType

Application

Layer(7)

Data

Messageandpacketcreation begins.DBaccessisonthis level.End-userprotocolssuchas FTP,SMTP,Telnet,andRAS workatthislayer

UsestheProtocolsFTP, HTTP,POP3,&SMTP anditsdeviceisthe Gateway

PDFGETrequests,HTTPGET, HTTPPOST,= websiteforms (login,uploadingphoto/video, submittingfeedback)

Reachresourcelimitsof servicesResource starvation

Applicationmonitoringisthepracticeof monitoringsoftwareapplicationsusinga dedicatedsetofalgorithms,technologies,and approachestodetectzerodayandapplication layer(Layer7attacks).Onceidentifiedthese attackscanbestoppedandtracedbacktoa specificsourcemoreeasilythanothertypesof DDoSattacks

Presentation

Layer(6)

Data

Translatesthedataformat from senderto receiver

Usesthe Protocols Compression& Encryption

MalformedSSLRequests-- InspectingSSL encryption packetsisresourceintensive. AttackersuseSSLtotunnel HTTPattackstotargettheserver

Theaffectedsystems couldstopacceptingSSL connectionsor automaticallyrestart

Tomitigate,consideroptionslikeoffloadingthe SSLfromtheorigininfrastructureand inspectingtheapplicationtrafficforsignsof attackstrafficorviolationsofpolicyatan applicationsdeliveryplatform(ADP).Agood ADPwillalsoensurethatyourtrafficisthenre- encryptedandforwardedbacktotheorigin infrastructurewithunencryptedcontentonly everresidinginprotectedmemoryonasecure bastionhost

Session(5)

Data

Governsestablishment, termination,andsyncofsession withintheOSoverthenetwork (ex:whenyoulogoffandon)

18 مرداد 1393 برچسب‌ها: مقالات
Web Browser Security Revisited (Part 1)
IRCAR201404211

Number: IRCAR201404211

Date: 2014/04/18

In this article, we'll take a look at the state of web browser security now, how it's changed over the years, some security-related factors to consider when selecting a browser, and how to configure whichever browser you choose for your own browsing and for your users, to make it as secure as possible.

Introduction

In many organizations, the web browser is the most-used Internet application, but some users and admins are basing their browser choice on outdated information. And even if you have selected the web browser with the most and best security features, that doesn't mean you're safe. Those features have to be properly configured and even then, there are vulnerabilities in every browser.

The security priority

In general the web browser is often thought of as a consumer application. Of course, it’s also an important business tool. It’s also one of the most commonly exploited attack vectors. Web browsers put your network and your users at risk because they connect to so many different sites all over the world, any of which could be (deliberately or unknowingly) hosting malware. Browsers run code – JavaScript, ActiveX controls, Flash, Silverlight, etc. It transmits (and in some cases stores) passwords used to access security-sensitive web sites. It may store information for automatic filling in of forms, including addresses, phone numbers, credit card and banking information.

Web browsers are complex pieces of software. On top of that, they run numerous add-ons (a.k.a. plug-ins or extensions) that are developed by third parties. This greatly extends the functionality of the browser but it also creates more risk of vulnerabilities and thus more opportunities for attackers to exploit those vulnerabilities.

The good news is that all of the popular web browsers – Chrome, Firefox, Internet Explorer, Opera, Safari (listed in alphabetical order) – are substantially more secure today than they were five years ago. All of the web browser vendors put a great deal of time and effort into building new security mechanisms into each new release of their software.

Interestingly, a recent poll from Sophos indicated that Mozilla Firefox is the web browser that’s “most trusted” by the survey respondents, garnering over 50 percent of the vote. Google Chrome was second with close to 27 percent, Microsoft Internet Explorer was third with 8 percent, Apple Safari coming in at a little over 7 percent, Opera at a bit less than 5 percent and Chromium (the base browser on which Chrome and the latest versions of Opera are built) with 3 percent.

But the browser most people trust isn’t necessarily the browser that’s most trustworthy. There have been a number of studies done by various organizations to compare the security of the popular browsers, and the results vary. Larry Seltzer, over on ZDNet, notes that “Contrary to aged conventional wisdom, recent versions of Internet Explorer are very secure, perhaps the most secure browser available.” And over on the Sophos blog, John Zorabedian opines that Chrome “could be” the most secure web browser. In the end, as InfoSecurity reported in July and as testing by NSS Labs showed, there actually is no definitive winner of the web browser security race. Some excel in one area, such as protecting users from phishing sites, while others do better at other things, such as keeping users from being tracked without their permission.

The moral of the story is that, regardless of which browser you or your end users choose, there will be risks involved in venturing out onto the world wide web. Those risks can be reduced, however, by proper configuration of the chosen browser and by practicing safe surfing habits. Now we’re going to take a closer look at each of the top browsers in their current incarnations, discuss the security measures they implement, and talk about how to configure them to make more secure (while preserving usability).

Browser Security Commonalities

No matter which browser(s) are in use in your organization, you know that the first key to security with any browser is to use the most recent version possible, because that’s the one that will have more security mechanisms built in. Vendors learn from past mistakes, and new versions will have patched vulnerabilities that were discovered in their predecessors.

However, new browser versions are released by some vendors seemingly every other day. It’s not always easy to keep up when you have a large number of machines to update. Even with automatic updates enabled, sometimes the updates don’t work. If users are allowed to download and install programs (not a good idea, but sometimes necessary under some circumstances), some of them may have multiple browsers installed on their machines.

And of course, with the BYOD trend, users have far more control over laptops and tablets that they personally own, but which connect to your network and can present a risk to the rest of the network if they become infected. It’s important to have software inventory tools and a management system that will let you know what versions of which applications are installed on each machine at any given time. It’s also important to have policies in place that require BYOD users to keep their applications up to date, as well as requiring that they have adequate anti-malware software installed and in use.

Another problem is that it’s not just the web browser itself that can be exploited. Browser vendors release APIs to allow third parties to create extensions that give the browser even more functionality, such as the ability to display PDFs via the Adobe Reader plug-in. The bad news is that all of those plug-ins/extensions come with potential vulnerabilities of their own. That means updating the browser isn’t enough; you also need to ensure that any add-ons are up to date, as well.

Web browser vendors are concerned about security, but they also build their browsers to appeal to users. Sometimes the two are in conflict. End users often care more about features and functionality than security. They want to be able to do what they want or need to do on the web, and they don’t want to have to jump through security hoops in order to do it. Therefore even when a browser is capable of strong security, those security mechanisms may be turned off by default to improve the user experience.

Security mechanisms such as encryption can slow down performance. Blocking potentially dangerous web content such as ActiveX controls or JavaScript can cause some websites to not work properly. Requiring sites to be “white listed” in order to be accessed can prevent users from going to safe (but not listed) sites they need in order to get the information to do their work. Vendors don’t want to alienate users and drive them to another browser, so you may find some of the high security features present but disabled.

Most browsers now use some type of sandboxing or isolation method to prevent what goes on in one browser tab from affecting what happens in other open tabs and to restrict web pages from affecting the operating system. Each browser tab runs in its own separate process on the computer, instead of all in one as older browsers did. That’s why you’ll see multiple instances of the browser application if you look at the processes in Task Manager.

If users need to have plug-ins or browser configurations that are less secure, in order to get their work done, one suggestion is to have them use a different browser (the one that is considered most secure) for any kind of sensitive transactions, such as financial transactions or those where they must send either personal information or confidential company information via web forms. The browser used for sensitive transactions should have no plug-ins or have them all disabled and all settings should be configured to their most secure levels. For even better security, the sensitive browser can be run in a virtual machine on an operating system that is dedicated to this one purpose.

Another issue is how browsers store information such as remembered passwords and personal information such as credit card numbers that is used for quickly filling in forms. Some browsers may store some information on the computer in unencrypted databases, which could potentially be accessed by an unauthorized person.

In Part 2, we’ll start to drill down into the specific security features of the different browsers, beginning with Internet Explorer.

Resource:
18 مرداد 1393 برچسب‌ها: مقالات
Website Security
IRCAR201404210
Date: 2014-04-16

Introduction

Every community organization, corporation, business, or government agency relies on an outward-facing website to provide information about themselves, announce an event, or sell a product or service. Consequently, public facing websites are often the most targeted attack vectors for malicious activity. Web server attacks include:

· Exploitation of software bugs in the web server

· Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks

· Compromising "backend" data through command injection attacks, such as Structured Query Language (SQL) injection; Lightweight Directory Access Protocol (LDAP) injection; and cross-site scripting (XSS)

· Website defacement for malicious purposes

· Using compromised web server capabilities to attack external entities

· Using a compromised web server to distribute malware.

There are a number of challenges associated with securing a web server because not only does the operating system need to be secured but so do the associated web applications and services running on the device. One of the most difficult aspects is often keeping abreast of new and emerging vulnerabilities to both the Operating system and the web applications as well as keeping those systems patched and up to date.

Mitigation Strategies

The purpose of this document is to provide basic guidelines and security safeguard concepts that can be applied to public facing websites to reduce the attack surface area or mitigate the effects of a compromise. It is recommended that organizations routinely conduct a risk assessment on their environment to identify weaknesses or vulnerabilities.

· Web Server Security:

o Recommended web server security.

§ Ensure that web server host systems are built with only essential applications and components required to perform their intended functions. All other applications should be removed or disabled. For example, a web server does not require web browsing capability and if a web server is not performing FTP functionality there is no need to have that service running. Removing or disabling any unused components will reduce the attack surface area.

§ Web servers should be designed with very strict access to any back end data.

§ Web SQL services:

Prevent applications from connecting to databases with privileged access.

Validate input for length, range, format, and type.

Restrict input to lists of acceptable characters and deny any other characters not on the list.

Limit the use of dynamic SQL code. Use prepared statements, queries with parameters, or stored procedures whenever possible.

o Recommended Operating System Security:

§ Accounts that enable access to the underlying operating system of the web server should follow the concept of least-privileges and should be unique for each individual. A single admin account will prevent non-repudiation of activity and limit forensic capabilities if a compromise occurs. Also, a web server should be considered a critical service and thus should require two- factor authentication.

§ Enforce a strong password creation policy for administrators such as:

Minimum password length of 15 characters for privileged accounts.

Use of strong passwords requiring alphanumeric, uppercase, lowercase, and special characters.

Require recurring password changes at least every 90-180 days.

Enable password history limits to prevent the reuse of previous passwords.

Prevent the use of personal information in usernames and passwords, such as phone numbers, date of birth, and first name [dot] last name.

Require the use of passphrases instead of passwords.

§ Change all default usernames and passwords.

§ Disable or delete all unused accounts such as Guest accounts.

§ Disable credential caching for critical systems if possible.

o Keep web servers patched and up to date.

o Monitor mailing lists and/or websites for security related announcements.

o Web servers should be built on isolated hardware or on secure multi-tenant virtualized technology with direct communication to potential other virtualized guests disabled. This can potentially help limit the damage or compromise of multiple services if a single service is attacked as well as reduce the attack surface area of a single service.

o Employ web authentication and encryption technologies such as SSL/TLS based upon the nature of web server data (e.g. sensitive, private, confidential, etc.).

Employ revision control processes to document all changes being made to the system, application, or web content.

· Secure Web Services:

Below is a list of possible mitigations an organization can consider to further secure web services and applications. Not all items will be applicable to all organizations, a balance must be struck between the cost benefits provided by each mitigation and the potential risk an organization is willing to accept for their web services.

o Enable extensive logging and collect the IP address of the system accessing the service, the username, the resource accessed, account privilege changes, whether the attempt was successful or not, and other potential suspect activities. Unusual/questionable access must be reported immediately and will require investigation.

o Data service replication – DoS and DDoS attacks are not new, but they are still occurring and have become a favorite attack method of some groups, so it is in the best interest of any organization to have applications and data replicated or backed up on a recurring basis, preferably to an offline storage location. Offline backup storage will help prevent tampering of the data and applications as well as provide redundancy in the event that the data and applications need to be moved to other platforms.

o Logging services are critical to provide non-repudiation and accountability for any transaction preformed on a server. Logging is also critical in identifying malicious activity after a compromise has occurred as well as potentially identifying malicious activity that is occurring. How much logging to enable and how often to archive the logs will be determined by how much storage space is available in your environment as well as how active your network is. Additional services or software may be required to support the level of security and accountability and non-repudiation that your environment requires.

o Secure software development and design – Secure software development is one of the most critical aspects in application security, simply because the less built-in vulnerabilities that any application has the less likely it is to be compromised.Another aspect of secure software is maintaining the security of the software. This can be accomplished through recurring patching and monitoring the Vulnerability Database for any new vulnerabilities.

o Securing web server infrastructure – Web servers should be located inside a secure Demilitarized Zone (DMZ) structure with one-way trust relationships configured to have the DMZ trust the internal network, but the internal network not trusting communications from the DMZ. Also consider restricting any communications or requests from web servers to internal resources.

In conclusion, web servers and services are responsible for providing web content and are a necessary component for many business and organizations. The extended loss of these services can have catastrophic results. Because of this it is essential to treat these services as essential and protect them as such.

Resource:

www.Us-cert.gov

18 مرداد 1393 برچسب‌ها: مقالات
صفحات: «« « ... 2 3 4 5 6 ... » »»