I am learning website languages, and i am still a beginner. I am building a website that uses registrations, logins, adds, and so on... First I used PDO in my php in order to prevent mysql injections. Anyway I was hacked, they did not delete the database but it is full of this e-mail 111-222-1933email#adress.tst, and a strange code. I think that they used acunetix to see the leaks of mine website.
My question is: Do you know whats he hacker did, and what measures (besides PDO) can i use in my website to have a little bit more of security?
Use http://www.php.net/manual/en/pdo.prepare.php to create paramerterised queries - only use quote as a last resort.
As for your website, it could be anything - review all server and firewall logs as a starting point.
I am not an expert in php, but I think PDO by itself does not protect you from sequel injections when you take input from the user. you still have to use the PDO method quote to protect yourself.
http://php.net/manual/en/pdo.quote.php
Related
i have to write a report based on an a simple SQL injection attack. In this report i have to provide screenshots of my "walkthrough" so i cannot use pictures of other tutorials on the web. Now my question is: can anybody tell me the names of some websites vulnerable to SQL injection attack on which i can test my attack legally? Thanks to Google dorks i have already found some vulnerable websites, but i think that running the attack over them is illegal. I want to avoid the setting up of a personal website for this purpose, but if there are no other solutions i need an help also in setting up this kind of site.
There is a web application called DVWA (Damn Vulnerable Web Application), it's not hosted on the internet. you have to download it and run as localhost on your computer. However it has a range of vulnerabilities, i have used it in the past for trying out a brute force attack. As its localhost its legal. it should be ideal for a walk through tutorial. I know you said that you didn't want to setup your own website, but the setup is a few minutes. Hope this Helps :D
Link: http://www.dvwa.co.uk/
I am currently working on security for a website (JSP) that contains 2 pages: a login and a data page. Once a user logs in, he is able to SELECT data from a specific table with read only access.
After browsing security risks online, I have wrote down a general list of what I might have to defend against
Injections
XSS
Auth / Session hijacking
CSRF
Direct Object Ref
Currently, I am reading about how to defend these attacks and what I should include in my code. However, I won't really know if my code actually works unless I test these attacks out for myself (and even then, there still might be other attacks that work). Right now, I just want some security, and thus I need to know how to produce these attacks so I can try them on my site.
Injections were simple as all I had to do what type '1'='1 in my code to reveal that it was flawed. Then I used prepared statements and SQL injections didn't work anymore.
How can I produce the rest of these attacks to see if my security atleast works against basic attacks?
(Also, is there perhaps some safe site or tool I can use to test out my vulnerabilities?)
I assume from your list that you're looking at the Open Web Application Security Project Top Ten. Good!
Really, the best advice I can give is to read through the OWASP site. A good first step would be to go through the individual links on that page (e.g. Broken Authentication and Session Management) and check the "Am I vulnerable?" section. Here are some further hints:
XSS
The XSS Cheat Sheet can be pretty helpful here. More examples than you can shake a stick at, ready to paste into your site.
CSRF
OWASP's wiki has a CSRF Testing Guide full of great links and suggestions.
Auth/Session hijacking
Well, are you using HTTPS? See this answer for more.
More resources
If you want to Go Deeper and do some real testing, here are some things you can do:
Read the Web Application Hacker's Handbook.
Try out some of the examples on http://hackthissite.org and the Google Gruyere project and see if you can break into them.
Download Kali Linux and learn to use some of the tools that come with it.
Go to a security conference or minicon near you and connect with other infosec people. Maybe I'll see you there :)
Web applications on uncompromised computers are vulnerable to XSS,CRSF,sql injection attacks and cookie stealing in unsecure wifi environments.
To prevent those security issues there are the folowing remedies
sql injection: a good datamapper(like linq-to-sql) does not have the risk of sql injection (am i naïeve to believe this?)
CSRF: Every form-post is verified with the <%:Html.AntiForgeryToken() %> (this is a token in a asp.net mvc environment that is stored in a cookie and verified on the server)
XSS: every form that is allowed to post html is converted, only bb code is allowed, the rest is encoded . All possible save actions are done with a post event so rogue img tags should have no effect
cookie stealing: https
Am i now invulnerable to web-based hacking attempts(when implemented correctly)? Or am i missing some other security issues in web-development?(except for possible holes in the OS platform or other software)
The easy answer is "No you're not invulnerable - nobody is!"
This is a good start, but there are a few other things you could do. The main one you haven't mentioned is validation of untrusted data against a white-list and this is important as it spans multiple exploits such as both SQLi and XSS. Take a look at OWASP Top 10 for .NET developers part 1: Injection and in particular, the section about "All input must be validated against a whitelist of acceptable value ranges".
Next up, you should apply the principle of least privilege to the accounts connecting to your SQL Server. See the heading under this name in the previous link.
Given you're working with ASP.NET, make sure Request Validation remains on and if you absolutely, positively need to disable it, just do it at a page level. More on this in Request Validation, DotNetNuke and design utopia.
For your output encoding, the main thing is to ensure that you're encoding for the right context. HTML encoding != JavaScript encoding != CSS encoding. More on this in OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS).
For the cookies, make them HTTP only and if possible, only allow them to be served securely (if you're happy to only run over HTTPS). Try putting your web.config through the web.config security analyser which will help point you in the right direction.
Another CSRF defense - albeit one with a usability impact - is CAPTCHA. Obviously you want to use this sparingly but if you've got any really critical functions you want to protect, this puts a pretty swift stop to it. More in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF).
Other than that, it sounds like you're aware of many of the important principles. It won't make you invulnerable, but it's a good start.
Am I now invulnerable to web-based hacking attempts?
Because, no matter how good you are, everyone makes mistakes, the answer is no. You almost certainly forgot to sanitize some input, or use some anti-forgery token. If you haven't now, you or another developer will as your application grows larger.
This is one of the reason we use frameworks - MVC, for example, will automatically generate anti-CSRF tokens, while LINQ-to-SQL (as you mentioned) will sanitize input for the database. So, if you are not already using a framework which makes anti-XSS and anti-CSRF measures the default, you should begin now.
Of course, these will protect you against these specific threats, but it's never possible to be secure against all threats. For instance, if you have an insecure SQL-connection password, it's possible that someone will brute-force your DB password and gain access. If you don't keep your versions of .Net/SQL-Server/everything up to date, you could be the victim of online worm (and even if you do, it's still possible to be zero-dayed).
There are even problems you can't solve in software: A script kiddie could DDOS your site. Your server-company could go bankrupt. A shady competitor could simply take a hedge-clippers to your internet line. Your warehouse could burn down. A developer could sell the source-code to a company in Russia.
The point is, again, you can't ever be secure against everything - you can only be secure against specific threats.
This is the definitive guide to web attacks. Also, I would recommend you use Metasploit against your web app.
It definitely is not enough! There are several other security issues you have to keep in mind when developing a web-app.
To get an overview you can use the OWASP Top-Ten
I think this is an very interesting post to read when thinking about web-security: What should a developer know before building a public web site?
There is a section about security that contains good links for most of the threats you are facing when developing web-apps.
The most important thing to keep in mind when thinking about security is:
Never trust user input!
[I am answering to this "old" question because I think it is always an actual topic.]
About what you didn't mention:
You missed a dangerous attack in MVC frameworks: Over Posting Attack
You also missed the most annoying threats: Denial of Service
You also should pay enough attention to file uploads (if any...) and many more...
About what you mentioned:
XSS is really really really waster and more annoying to mitigate. There are several types of encoding including Html Encoding, Javascript Encoding, CSS Encoding, Html Attribute Encoding, Url Encoding, ...
Each of them should be performed to the proper content, in the proper place - i.e. Just doing Html Encoding the content is not enough in all situations.
And the most annoying about XSS, is that there are some situations that you should perform Combinational Encoding(i.e. first JavascriptEncode and then HtmlEncode...!!!)
Take a look at the following link to become more familiar with a nightmare called XSS...!!!
XSS Filter Evasion Cheat Sheet - OWASP
I am planning to get my website development outsourced to a third party developer. Need your help in deciding on how/ what technology to be used to make it very secure. Since I am not a techie I need the website developed in a way, so that it is easy for me to maintain it and modify content easily if required.
The main purpose of the website is to provide company information about services offered and then also to exchange documents and other file using FTP server. Will be sending out surevey and newletters sometime
Looking for your advice to guide me to the right direction
As I already said on another answer, security is not a product, it's a process.
There isn't a 'secure' software or language. What makes your website/application secure is how it is developed and how the website is maintained.
There is no ready-made solution that, one time or another, won't be hacked.
If the people you are outsourcing to don't understand this, outsource to someone else.
Making your web server "hardened" against attack is best left to the expert sys-admins at Server Fault. However regardless of what technology you use, there is one HUGE thing an end user can do to protect her/his online assets:
USE STRONG PASSWORDS
You can make a site secure using any technology/language/framework.
It's the code quality that makes a site insecure, not the technology/language/framework.
There is no single "correct" language to use -- it's possible to write an insecure website in any language.
The key is hiring staff that have the skill and experience in developing secure web solutions, and also making sure that the system is tested often by external specialists
For the sake of simplicity I want to use admin links like this for a site:
http://sitename.com/somegibberish.php?othergibberish=...
So the actual URL and the parameter would be some completely random string which only I would know.
I know security through obscurity is generally a bad idea, but is it a realistic threat someone can find out the URL? Don't take the employees of the hosting company and eavesdroppers on the line into account, because it is a toy site, not something important and the hosting company doesn't give me secure FTP anyway, so I'm only concerned about normal visitors.
Is there a way of someone finding this URL? It wouldn't be anywhere on the web, so Google won't now it about either. I hope, at least. :)
Any other hole in my scheme which I don't see?
Well, if you could guarantee only you would ever know it, it would work. Unfortunately, even ignoring malicious men in the middle, there are many ways it can leak out...
It will appear in the access logs of your provider, which might end up on Google (and are certainly read by the hosting admins)
It's in your browsing history. Plugins, extensions etc have access to this, and often use upload it elsewhere (i.e. StumbleUpon).
Any proxy servers along the line see it clearly
It could turn up as a Referer to another site
some completely random string
which only I would know.
Sounds like a password to me. :-)
If you're going to have to remember a secret string I would suggest doing usernames and passwords "properly" as HTTP servers will have been written to not leak password information; the same is not true of URLs.
This may only be a toy site but why not practice setting up security properly as it won't matter if you get it wrong. So hopefully, if you do have a site which you need to secure in future you'll have already made all your mistakes.
I know security through obscurity is
generally a very bad idea,
Fixed it for you.
The danger here is that you might get in the habit of "oh, it worked for Toy such-and-such site, so I won't bother implementing real security on this other site."
You would do a disservice to yourself (and any clients/users of your system) if you ignore Kerckhoff's Principle.
That being said, rolling your own security system is a bad idea. Smarter people have already created security libraries in the other major languages, and even smarter people have reviewed and tweaked those libraries. Use them.
It could appear on the web via a "Referer leak". Say your page links to my page at http://entrian.com/, and I publish my web server referer logs on the web. There'll be an entry saying that http://entrian.com/ was accessed from http://sitename.com/somegibberish.php?othergibberish=...
As long as the "login-URL" never posted anywhere, there shouldn't be any way for search engines to find it. And if it's just a small, personal toy-site with no personal or really important content, I see this as a fast and decent-working solution regarding security compared to implementing some form of proper login/authorization system.
If the site is getting a big number of users and lots of content, or simply becomes more than a "toy site", I'd advice you to do it the proper way
I don't know what your toy admin page would display, but keep in mind that when loading external images or linking to somewhere else, your referrer is going to publicize your URL.
If you change http into https, then at least the url will not be visible to anyone sniffing on the network.
(the caveat here is that you also need to consider that very obscure login system can leave interesting traces to be found in the network traces (MITM), somewhere on the site/target for enabling priv.elevation, or on the system you use to log in if that one is no longer secure and some prefer admin login looking no different from a standard user login to avoid that)
You could require that some action be taken # of times and with some number of seconds of delays between the times. After this action,delay,action,delay,action pattern was noticed, the admin interface would become available for login. And the urls used in the interface could be randomized each time with a single use url generated after that pattern. Further, you could only expose this interface through some tunnel and only for a minute on a port encoded by the delays.
If you could do all that in a manner that didn't stand out in the logs, that'd be "clever" but you could also open up new holes by writing all that code and it goes against "keep it simple stupid".