Hacking Your Own Site - Solutions to Website Vulnerabilities
(Page 3 of 3 )
Closely related to hidden field manipulation, buffer overruns are engineered in a similar fashion; any text input field with a maxchar=n property can be used to potentially shut down the server. The source code can be accessed, and the maxchar property removed. The hacker then enters, say, 10,000 ones and submits the form. What happens next? The server shuts down, taking your business with it. A semi-secure solution to this would again be to encrypt any HTML form source. A better solution would be to allocate memory dynamically, therefore not presetting the memory buffer to a certain size, or writing a function that checks the length of the input before passing the results to the server. If the input exceeds the memory allocation, simply pass back a NULL value.
A simple, yet effective trick in deterring hackers is to configure your web server to hand out customised error 404 pages with a status of 200 when a resource is not found. Most genuine users will not even notice, and a hacker using software to scan for available resources will think they have stumbled across a gold mine. When the hacker goes to check, they will find that they have been duped and hopefully see examining your site further as a waste of time. This could be seen as hacking hackers or the hacker becoming the hacked...
Netcat
You could take this one step further and use an old UNIX application called netcat to crash anyone who attempts to hack your site. Netcat makes and accepts TCP connections, but it can be used by a hacker for many things, including obtaining remote access to a shell, port-scanning and even hi-jacking services and bypassing firewalls. It can also be used to monitor ports and flood suspicious requests, similar to a buffer over-run, by using it to pretend you are running a service that you are not and using the 'yes' command when someone tries to exploit that service. Netcat is an extremely powerful application in itself and is usually part of any self-respecting hackers' tool-kit. Morally, you could look at this as hitting them back first.
Conclusion
I hope that I have drawn your attention to some of the more basic but often overlooked entry-points that a hacker may use to gain entry to your web applications, and highlighted the need for basic auditing of the security enforcement of your site.
This article is not intended to be a complete solution for defense against hacking, but more the starting point for your considerations. No site is completely hack-proof, but there are few sites that really need to be. As a web developer ,your main security concern is first to assess how much security you will actually need. The more secure you need to be, the more your aims will move toward hiring the services of a professional security solution.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
| · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | | |
|
