todhost:
Credit: https://www.todhost.com/blog/digital-marketing-seo/224-how-to-prevent-the-most-common-application-attacks-against-websites


The Web hosts a large set of applications all aimed at enhancing the productivity of users such as Google Docs, calculators, email, storage, maps, weather and news, everything that is needed daily by the users. Application attacks are usually the hardest to defend against. The vulnerabilities encountered within the application layer often rely on complex user input scenarios that are hard to define with an intrusion detection signature. This layer is also the most accessible and the most exposed to the outside world. For the application to function, it must be accessible over Port 80 (HTTP) or Port 443 (HTTPS).

In 2014, SQL injections, a type of application attack, were responsible for 8.1 percent of all data breaches. That makes it the third most used type of attack, behind malware and distributed denial-of-service attacks. There are also other common application attacks such as security misconfiguration, using components with known vulnerabilities and cross-site scripting. Attackers are able to manipulate application input and obtain confidential data without being detected by network defense systems.

Most vulnerabilities found in Web applications are unknown to security defense systems; these are called zero-day vulnerabilities. This is because these vulnerabilities are specific to each application and have never been known before. A skilled attacker can easily find these vulnerabilities and exploit the issue without being detected.

The best defense against these attacks is to develop secure applications. Developers must be aware of how application attacks work and build software defenses right into their applications.

Educating and informing developers about application vulnerabilities is the goal of the Open Web Application Security Project (OWASP). The organization has put together a list of the 10 most common application attacks. This list is renewed every three years, with the latest refresh in 2013.

The IBM Security Ethical Hacking Team shares this goal. With this in mind. So let's take some brief look at the 10 most common application attacks.

1. Injection

Injections let attackers modify a back-end statement of command through unsanitized user input. SQL injection is currently the most common form of attack you will find on the web, this kind of attack occurs when a website is not coded properly and the hacking tools used to find weaknesses and take advantage of them are commonly available online. This kind of exploit is easy enough to accomplish that even inexperienced hackers can accomplish mischief. However, in the hands of the very skilled hacker, a web code weakness can reveal root level access of web servers and from there attacks on other networked servers can be accomplished.

SQL injection is the use of these publicly available fields to gain entry to a database. This is done by entering SQL commands into form fields instead of the properly required data. Improperly coded forms allow a hacker to use them as an entry point to your database at which point the data in the database may become visible and access to other databases on the same server or other servers in the network may be possible.

Web site features such as contact forms, logon pages, support requests, search functions, feedback fields, shopping carts and even the functions that deliver dynamic web page content, are all susceptible to SQL injection attack because they contain fields that require input data and allow at least some SQL commands to pass through directly to the database.

Defense Against SQL Injection

Because web sites require constant access to the database, firewalls provide little or no defense against SQL injection attacks. Your website is public and firewalls must be set to allow every site visitor access to your database, usually over port 80/443.

Antivirus programs are equally ineffective at blocking SQL injection attacks. They are intended to spot and stop an entirely different kind of incoming data.

The most commonly used SQL injection defense is made up of two components. First there is routine updating and patching of all servers, services and applications which of course has many advantages and is common practice. Then there is producing and using well written and well tested website code that disallows unexpected SQL commands.

These two defenses are by definition enough to halt any SQL injection attack.

2. Broken Authentication and Session Management

Securely authenticating users, managing their sessions when connected, and ensuring proper logout when the sessions end are essential activities when delivering web applications. Each of these activities can provide a target for malicious attackers trying to compromise a web application.

3. Forms of Session Management Compromise and How to Mitigate the Risk

Password storage in plain text - Account passwords should not be held in plain text locally in storage within the web application infrastructure. Neither on physical storage or in memory. Passwords that need to be held should always be protected by a strong cryptographic hashing algorithm. Many commercial solutions are available to ensure that passwords stored locally can be encrypted.
Password transmission in in plain text - Plain text passwords can easily be intercepted on both wired and wireless networks. In order to fully protect passwords, it is good to secure the network session with Secure Sockets Layer (SSL), or Transport Layer Security (TLS) encryption. Sending the password over the network in a hashed format isn't good enough. An attacker could grab the hashed password in transit and send it back to the server without having to decrypt it. Adding SSL with certificates to protect transmission prevents this. SSL encryption is a resource intensive operation. It is ideally a process that should be handed off to a device that is optimised to perform it.
Using passwords that are easy to guess or brute force - Passwords should not be common words, simple and short that a brute force algorithm used by an attacker could stumble upon the password in a reasonable time. There should be a password policy in place that mandates a certain length of password, requires special characters, prevents password reuse, and forces periodic password changes.
Allowing unlimited logon attempts - Account security settings should be set to only allow a limited number of failed password attempts before an account is locked. This is to prevent brute force attacks.
Poorly implemented password change mechanism - Only the actual user of an account should be able to successfully request and execute a change in their password.
Insecure password recovery features - If a user forgets their password and requests a reset then they should be with a mechanism to confirm their identity that is used for allowing them to change their password.
Exposing account lists - Lists of accounts available for access to web applications should not be viewable. Attackers can use the accounts as a starting point for attacks.
Session IDs exposed in URLs - In order to make sure that multiple requests are associated with the users they are bundled into sessions. A session ID as an identifier to link http requests with certain clients. These session IDs should not be shown in the URLs that client devices are using to communicate with the web servers. If they are an attacker could copy the Session ID and potentially gain access to that clients authenticated session and compromise data.
Session ID creation is not controlled centrally - Creating Session IDs should not be under the control of users and clients. They should rather be generated, controlled, and secured centrally by the authentication and authorisation mechanism.
Session IDs don't expire after time period or on logout - It is vital that Session IDs have a built in time to live and that they are destroyed when a user logs out of a web application. This prevents an attacker using the Back button on a browser to establish a valid session.
Browsers caching Session IDs - Session IDs should not be stored between browser sessions. They should be destroyed when a browser is closed.
Session IDs not using SSL - Session IDs are vulnerable to hijacking when they are passed across the network with http requests. As with hashed passwords its essential that session ID tokens are protected with SSL to ensure they remain secure.
Trust relationships between components delivering a service - Many web applications are made up of component services that deliver data and functionality for users. It is not recommended to set up trusted relationships between these components. Interaction between different components should be based on authentication and authorisation requests that are initiated when required and destroyed when done.

4. Cross-Site Scripting

Cross-site scripting is a type of vulnerability that lets attackers insert Javascript in the pages of a trusted site. By doing so, they can completely alter the contents.

To protect against script injections and attempts to modify PHP's global and request variables, add the following code to your site's root .htaccess file

IfModule mod_rewrite.c
RewriteCond %{QUERY_STRING} (\|%3C).*script.*(\|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F,L]
IfModule


5. Security Misconfiguration

Moving into the top five, we'e exploring another extremely dangerous category of flaws that deals with the incorrect misconfiguration of the server or of the application itself.

Running the application with debug enabled in production.
Having directory listing enabled on the server, which leaks valuable information.
Running outdated software (think WordPress plugins, old PhpMyAdmin).
Having unnecessary services running on the machine.
Not changing default keys and passwords. (Happens way more frequently than you'd believe!)
Revealing error handling information to the attackers, such as stack traces.

Prevention: Make sure to install the latest security updates. Remove any unnecessary features or plugins

6. Sensitive Data Exposure

This category deals with a lack of data encryption in transport and at rest. If your Web applications do not properly protect sensitive data, such as credit cards or authentication credentials, attackers can steal or modify the data to conduct credit card fraud, identity theft or other crimes.

Make sure to install the latest security updates

7. Missing Function Level Access Control

This category covers situations in which higher-privilege functionality is hidden from a lower-privilege or unauthenticated user rather than being enforced through access controls.

8. Cross-Site Request Forgery

This type of attack is used in conjunction with social engineering. It allows attackers to trick users into performing actions without their knowledge.

The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user's session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.

9. Using Components With Known Vulnerabilities

This category is about using unpatched third-party components. Attackers can easily exploit old third-party components because their vulnerabilities have been publicized, and tools and proof of concepts often allow cybercriminals to take advantage of these flaws with ease. Any script kiddie can conduct an exploit.

Prevention: Make sure to install the latest security updates

10. Unvalidated Redirects and Forwards

This category of vulnerabilities is used in phishing attacks in which the victim is tricked into navigating to a malicious site. Attackers can manipulate the URLs of a trusted site to redirect to an unwanted location.

Prevention: Make sure to install the latest security updates and run the latest version of software including plugins, components and modules.

sunkieisland:
most bloggers wey suppose check this thread out, they been go their way.



when I go begin hack Nlanders blog. them go take security important

jonnyboy4u:
Hosting your blogs or sites, you should try qservers.net .

You can view their international reviews below:

https://www.bitcatcha.com/research/web-hosting-nigeria-websites/