Top 10 web attacks

When you decide to make your own web app, one of the first things to do is to be aware of hackers. Let's see what the elite of the web can do with your app:

1.Injection - one of the most common and easiest ways to say hello without knocking the door. As many web developers of apps/websites don't really pay attention to absence checks, we can pass something called tautologies and get the access without even having a valid account.

2. Broken authentication and session management - please, try to avoid custom authentication and refer to open source (just kidding) / most popular and often patched modules. The server with the wrong parameters could accept client's generated session ids. This could cause unwanted actions, especially where users store their SSN and credit cards information.

3. Cross-site scripting or XSS - malicious code that executes on the client's side. Usually delivered with social engineering, it provides large possibilities for the elite to gather cookies, sessions and impersonate the victim. The recent HTML 5 and its APIs make it possible to get someone's location, access to the webcam and microphone. That's why we pay so much attention to JS while going on the dark web. Make sure to sanitize the inputs through your website/application!

4. Broken access control - basically gathering the functionality that are out of user's privileges. We can get the information that we are not supposed to see and actions we can't perform simply by playing around with urls, UI, APIs. By using control lists based on the account group and disabling function execution by default may save you from unrestricted access.

5. Security misconfiguration - allowing the hacker to see your server details, version of the engine ( especially from open source ), physical location of the server, code details and wrong permissions ( read / write ) gives the green light to hackers. You will be surprised how many people actually keep default passwords and logins in their systems.

6. Data exposure - many websites still use HTTP as their main protocol between server and client. Passwords, logins and passwords are stored encrypted on the databases or may have vulnerable algorithms such as MD5, DES, SHA-0, SHA-1. If somehow the tokens are in public access, most likely your application will be hacked.

7. Insufficient attack protection - classic one is brute force attack on the login page. Blogs, forums have the same login as the author of the post-message, which makes it easy to hack, especially when there are no lock downs on the failed login attempts. Use simple blacklists written on the server side to prevent the brute force script from trying different combinations of passwords. Malicious activity could be detected and prevent the DDoS of your app. Most VPs services provide built-in filters, but most of them just put your app down for ~24 hours to avoid further overload on the server from the botnet.

8. Cross site request forgery - look at the Paypal and other payment systems - there is a generic link based on what you are trying to do, either send money or deposit them. The idea behind CSRF is to understand the pattern and use this pattern to perform the action from your session, for ex. to send money to mr. X. How would you ask? Pretty easy, starting from the embedded image with the link to perform unwanted action from the victim's browser: easymoney.xyz/send=100/to=x

When the victim suddenly hits the button, the money will be sent from the website easymoney to mr.x. If your app works with finance, please, please, please involve additional encrypted keys before any operation will occur. If so, the browser will check if the key is correct and process the request.

9. Using components with exploits - we are aware of your server details, version of your JS libraries and additional modules you got from open source. Server configuration that you left open to us - we track all that and simply know the way to open the door. Don't leave stuff unpatched! Keep updating the frameworks if possible and pray! :)

10. Vulnerable APIs - just use the simple logic, put your business needs under strict permissions for different groups. The methods briefly discussed before are the part of APIs vulnerability, one piece depends on the other.

To sum up - stay safe and manage your architecture in advance on the stage of blueprinting. Don't build and then think of security, especially when going to production and working with users. The cost of mistakes not taking threats seriously are sleepless nights, stress and a lot of money. Don't lose reputation and your customer/client/user's trust.