Top ten hacker attacks on web apps for dummies

Dmitrii Korolkov

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 way 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 authefication and session managment – 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, provides large possibilities for elite to gather cookies, sessions and impersonate the victim. The resent HTML 5 and it’s 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 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 suppose 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 algoritms 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’s 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 you 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 generic link based on what you are trying to do, either send money or deposit them. The ide 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 embeded image with the link to perform unwanted action from the victim’s browser:

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 key 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 you 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 peace depends on the another.

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 mistake not taking threats seriously are sleepless nights, stress and a lot of money. Don’t loose reputation and you customer/client/user’s trust. 

proudly runned on WordPress