Can someone explain to me the real danger, XSS can do on internal sites using Windows Authentication. I know firewall can be break and hacker can access internal site but for now let's not focus on that. I just want to know what and internal employee(hacker) can do on a Windows Authentication environment using XSS.
Thanks,
Windows Authentication does not prevent XSS attacks or help detecting them, so it is irrelevant to the question.
An internal employee (hacker) can do all what any external hacker can do.... only about 10 times easier. Here is a quick comparison.
But practically speaking, because internal hackers can access information much easier and in more ways than external hackers, they usually use less sophisticated methods. They focus more on covering their tracks.
But then, who said that internal hackers have to do it from inside? Unlike the external hackers, they have the option to do it from both inside and outside. An employee can go to a coffee shop and perform an XSS attack (or any other attack) just like any external hacker. Their much deeper knowledge of the internal systems will make any attack much easier. Also IT employees can use the projects that are under their control to attack (XSS or otherwise) other projects that are not under their control.
The possibilities are limitless. It's nearly impossible to protect yourself from internal hackers. Your only hope is to find the tracks. The good news is that if you find the tracks, it is usually much easier to reach and punish internal hackers as long as they haven't fled the country.
That, however, doesn't mean that you don't need to bother. Your coworker can probably access your office, and even break the lock on your drawer and reach your wallet that you put there while you're having your lunch in the kitchen, but you still don't put your wallet on the desk in plain sight, do you? Well, at least you don't leave in on the table in the conference room. The better you protect your assets, the more sophisticated methods the hackers have to use, and the more likely they will leave tracks behind.
You can't ignore the security aspects for your internal Websites just because of the fact you believe that they aren't visibile to the outside world.
There were so far many cases of different companies ignoring the security of their internal apps just because they think it's safe. But...
you said your Website is behind a firewall. Are you 100% sure of the firewall configurations and that no one would be able to access it?
Are you 100% sure that your firewall is safe and no one could break it?
Are you 100% of your server configurations and this website is only accessible from your Internal network?
Are you 100% sure that there's no possible way to access this internal Website/Database/App or whatever using the public Interface that is visible to the outside world?
Also you mentioned that it's vulnerable for XSS. The fact that you ignored XSS could also mean that there are more dangerous vulnerabilities that you haven't found yet or maybe didn't bother to find because you believe that it's just an internal website.
Also as #Racil Hilan pointed out in his answer. An insider could also exploit such a vulnerability.
Even for an internal website, XSS prevention is important, because of what #shawkyz1 said, but, in my opinion, more so because of what #Racil-Hilan said.
The easiest way to gain access to a company's data is to apply for a job. If you're inside, you're trusted. Imagine that an employee is pissed off with the company, for example because he's heard he'll be laid off. He can cause tremendous damage with XSS, for example by injecting a script which also pipes all input to a location from which he can steal it as his leisure.
Or perhaps he doesn't even steal the data, but cause tremendous misinformation by slightly altering messages users try to send, for example by randomly incrementing numbers, or with a small change exchanging "do" and "do not".
Related
Not only to the browser the request was made, but all the others. Or anywhere else which makes your server be aware of the same user.
You won't be able to do this with cookies, but there are other sneaky ways around this via evercookies and techniques like it. One recent development has been canvas-fingerprinting, which is probably too complicated for you to develop by yourself unless you have extensive canvas js experience. These techniques generally can be summed up as:
don't use cookies, but rather innate properties of the users computer
such as fonts, graphics processing speed, mouse movement or others to
identify repeat-visit clients
If you don't have a lot of mobile clients, a very simple but error-prone way to do this is to just save your previously-visited ip addresses on the server and look up if that ip has visited before.
Please be aware, though, that using evercookies or similar techniques on your site may violate privacy guidelines, or possibly even laws in some places. You probably should not do this, but searching the terms above may give you some ideas.
Situation: The dba is an offsite contractor who keeps the entire DAL code checked out in TFS. It would be nice as the front end developer to be able to add columns, and tweak procs and whatnot, without having to rely on waiting for this dude to respond to your emails to do the work.
Question: What would be a recommended solution/process that would allow for more rapid/agile development, while maintaining data integrity as well as peace love and happiness among the team?
Im getting some good feedback on Programmers HERE
There is no general technical answer to your question (unless you can define a very limited kind of needed access, which can be supplied via an API he provides for you in the DAL, etc.).
Assuming you already tried to talk with him and probably even escalated the issue, there is probably a valid reason for limiting access (security, data model integrity, performance tuning, version control etc.).
Try to understand the reasoning behind his approach, and to better define your actual needs, it is possible that after that you can formulate an improvement to your architecture (such as the aforementioned API) or your development process. Most importantly, talk frankly about your concerns, communication can go a long way, as long as you are willing to understand the other side.
This is the first time I have been faced with someone trying to penetrate a website I have created. What can I do to put a stop to the attempts?
As a side note, their sql injection stands no chance of ever working and there isn't any data that we have that isn't already available by anyone using this site normally.
Appended:
I think the code part is covered for most XSS and sql injection but I am definitely considering a security audit. I was just curious about the response. Am I really only limited to blocking ip addresses?
If you already are protected against SQL injections, you've got a major attack covered. The next biggest threat (in my opinion) would be Cross-Site Scripting (XSS) since it would allow an attacker to have another user do something malicious, making it hard to track that activity.
You should also be aware of Cross-Site Request Forgeries (CSRF), since that is one that many people seem to miss a lot of times.
I would take a look at OWASP's Top 10 Web Security Vulnerabilities and make sure you protect against all 10 them as best as possible. Any one of them could seriously open yourself up to attackers if you aren't careful.
Unless this is your first public website, all of the websites you have worked on were under attack roughly 3 minutes in to being accessible whether you knew it or not.
A couple things you can start doing are:
Start blocking the IPs that attacks are coming from. This isn't always feasible as IP addresses frequently change and some types of attacks can work with a spoofed address.
Put an intrusion detection system (IDS) in place and start monitoring everything.
Verify your firewalls are working correctly and monitor the attack vectors. Make sure everything they are going after is pretty well secured.
This answer comes from another one that I answered about IIS getting hacked:
Hopefully you've had your IIS logfiles
turned on and hopefully the hacker
didn't erase them. By default they're
located here:
c:\winnt\system32\LogFiles\W3SVC1 and
will generally be named after the
date.
Then it's probably helpful to figure
out how to use log parser (from
Microsoft), which is free. Then use
this guide to help you with
looking forensically at your logfiles.
Do you have a firewall because it's
syslogs might be helpful.
Another decent tool to help you find
sql injection issues is to go
here and download HP's Scrawlr.
If you have any more questions about
what you've found, come back and ask.
Is it many sources or just a few IP's? We've had a few IP's do shadowy things and have used IIS to block them specifically. If it's a coordinated attack from multiple sources this won't help.
Where do you host your customers' ASP.NET sites? I am about to develop a few sites, and I am looking for a good place to host (cheap, fast, good bandwidth, good storage, updates, service packs, etc.)
I have also thought about earning revenue for the hosting/domain, even though I am not actually hosting it (kinda sounds bad when you put it out there). Basically, I would just handle the hosting/domain costs and bill the customer, with a bit of markup. They wont know anything about the host, unless they go digging. Does anyone else incorporate this into their business model? What are the pros/cons?
I like webhost4life. I've tried hosting customer stuff -- you can't charge them enough to deal with the pain. It's much better to give it up to somebody else to deal with the bandwidth and SLAs.
I've used Brinkster for several years & never had any unplanned outages or any real problems. Keep in mind that the sites I've worked on aren't high-volume sites (local restaurants, etc) so I haven't really pushed the envelope bandwidth-wise. Pricing is good & support has always helped me out when I needed it.
A note on marking up hosting...I'm a one-person shop & I tried this once (for a short time), and regretted it immediately. Every tiny email issue, Outlook configuration setting, etc. will result in a customer phone call to you. YMMV, but the markup was never profitable or worthwhile for me personally.
Peer1 is a bit expensive but offers an excellent support when something goes wrong (DNS, email, dabase, service pack...). They help you configure your server and take care of security aspects (amongmany others).
I also use ServerBeach (Peer1's little brother), its self-managed hosting which means you have to take care yourself of the security, the server's configuration, the service packs,... more flexible and less expensive. Support is also excellent.
This is a shameless information gathering exercise for my own book.
One of the talks I give in the community is an introduction to web site vulnerabilities. Usually during the talk I can see at least two members of the audience go very pale; and this is basic stuff, Cross Site Scripting, SQL Injection, Information Leakage, Cross Site Form Requests and so on.
So, if you can think back to being one, as a beginning web developer (be it ASP.NET or not) what do you feel would be useful information about web security and how to develop securely? I will already be covering the OWASP Top Ten
(And yes this means stackoverflow will be in the acknowledgements list if someone comes up with something I haven't thought of yet!)
It's all done now, and published, thank you all for your responses
First, I would point out the insecurities of the web in a way that makes them accesible to people for whom developing with security in mind may (unfortunately) be a new concept. For example, show them how to intercept an HTTP header and implement an XSS attack. The reason you want to show them the attacks is so they themselves have a better idea of what they're defending against. Talking about security beyond that is great, but without understanding the type of attack they're meant to thwart, it will be hard for them to accurately "test" their systems for security. Once they can test for security by trying to intercept messages, spoof headers, etc. then they at least know if whatever security they're trying to implement is working or not. You can teach them whatever methods you want for implementing that security with confidence, knowing if they get it wrong, they will actually know about it because it will fail the security tests you showed them to try.
Defensive programming as an archetypal topic which covers all the particular attacks, as most, if not all, of them are caused by not thinking defensively enough.
Make that subject the central column of the book . What would've served me well back then was knowing about techniques to never trust anything, not just one stop tips, like "do not allow SQL comments or special chars in your input".
Another interesting thing I'd love to have learned earlier is how to actually test for them.
I think all vulnerabilities are based off of programmers not thinking, either momentary lapses of judgement, or something they haven't thought of. One big vulnerability that was in an application that I was tasked to "fix up", was the fact that they had returned 0 (Zero) from the authentication method when the user that was logging in was an administrator. Because of the fact that the variable was initialized originally as 0, if any issues happened such as the database being down, which caused it to throw an exception. The variable would never be set to the proper "security code" and the user would then have admin access to the site. Absolutely horrible thought went into that process. So, that brings me to a major security concept; Never set the initial value of a variable representing a "security level" or anything of that sort, to something that represents total god control of the site. Better yet, use existing libraries out there that have gone through the fire of being used in massive amounts of production environments for a long period of time.
I would like to see how ASP.NET security is different from ASP Classic security.
Foxes
Good to hear that you will have the OWASP Top Ten. Why not also include coverage of the SANS/CWE Top 25 Programming mistakes.
How to make sure your security method is scalable with SQL Server. Especially how to avoid having SQL Server serialize requests from multiple users because they all connect with the same ID...
I always try to show the worst-case scenario on things that might go wrong. For instance on how a cross-site script injection can work as a black-box attack that even works on pages in the application that a hacker can’t access himself or how even an SQL injection can work as a black box and how a hacker can steal your sensitive business data, even when your website connects to your database with a normal non-privileged login account.