drupal Cross Site Scripting (Reflected) - drupal

Site has ran in the OWASP ZAP Testing Tool, Getting thowing the cross site scripting error.
please share some remediation Technique to fix XSS Problem.
URL: example.com/sites/javascript:alert(1);/modules/lightbox2/js
Parameter: all
This tool does not provided the following information
1. in which place / which file hacking may occur.
Please advise to how to fix the XSS problem

It looks like the injection might be falling inside of a link href, iframe src, or some other place that handles URL redirection. It is really not possible to tell without seeing where the reflection is in the source or generated source (DOM) of the page.
A generic suggestion would be to have the application remove javascript: (and the various ways of encoding it such as URL, HTML, etc) from user input.

Related

Can someone give me an overview of ASP.net and how it's different from technologies such as php?

I've been doing the html and css for a site, sending it off to a guy to implement in a web server. I get a call from the designer freaking out about the progress, saying the clients aren't happy. He wants me to personally integrate my css with what's on the site. The site is done in ASP.net, time is short, and I'm a little in over my head. I have an understanding of how php works, but have never worked extensively with it.
Looking at the stuff on the ftp, I can't even find equivalent of the index.html file (I know that when I go to the site itself, there is nothing after the base url, i.e., www.site.com/ brings me to the homepage.)
Can anyone give me a few tips or links as to what I am to do with this, or where to even being navigating this site?
EDIT: It's -not- a .Net Web Application, from the looks of it.
ASP.Net can be run in a compiled or a scripted environment. It is important to understand which environment your client has. If it is completely scripted, then you are likely looking for the default.aspx file and it's contents. If it is a compiled environment, you may be in for a ride. A compiled site may incorporate "master pages" as a templating engine, and then you'll need to apply your html/css modifications in several places.
You should start with the default.aspx page if there is one. Look for master page directives (it'll be named something like masterpage.master). If there isn't one, then you're in luck you'll just need to implement your changes on a page by page basis. The aspx page will be in a templated xml format so avoid touching tags that involve touching
If you are making changes to divs and structures of that nature, you may need to modify the CssClass attribute of the controls. I would recommend however that you make a back up, give it a shot, and under no circumstances attempt to do something that you aren't really ready to do. You will only anger the client and ruin your rep. It may actually be prudent to contact an actual ASP.Net developer to analyze the files separately and determine what you need to do.
I suggest that you read the Wikipedia article about ASP.NET to get familiarized with it as it summarizes the basic building structures.
Then, just to get you started: take a look at the more recent ASP.NET MVC (Model-View-Controller) paradigm. There's also development in what is called ASP.NET WebForms.
For example: when you go to www.site.com/ (known as friendly URLs) it may be redirecting you to an action method inside a controller. It's called routing. There's also URL rewrite.
In the MVC world a Controller can send/redirect the user to a specific View/Page.
A View (.aspx form/page) that contais HTML markup and CSS on the server side is basically an HTML page (.htm) page that'll be rendered on the client side.

Security problem

I have a security problem in my website. A script code was added into my all pages like "<script src="Ip address/viewpic.asp"></script>" . It is between </head> and <body> tag. Now Google says "this site may be hartful for your pc!" about my site. How can i secure my website? I use C# and Visual Studio 2008.
You have been hacked. This code that has been added to your site is trying to hack web browsers that visit your site.
This could have happened a number of ways. The easist thing for you to do is to download an anti-virus like AVG and scan any machines with access to the site. There is malware that looks for FTP connections, it grabs the username/password then logs in and modifies files it finds. You should be using SFTP which can be installed under windows, FTP is only used by people who don't know any better or love to get hacked, or both.
The more complex possibility is that there is a vulnerability in your site. This requires a professional (Like me) to track down and fix. Acunetix can help find flaws in your site, but this might not find the vulnerability that was used to break in.
Edit: Assuming that the script is your own and not malicious:
You should not have any code between </head> and <body> - Otherwise you have got a <script> tag as a direct child of <html> which is not allowed.
Put the <script> tag inside <body> at the correct place where you want the script to execute, to correct the structural issue but you need to provide some more information about the exact error messages you are seeing about security as I'm not aware that Google shows error messages within its search listings and I dont have Google Toolbar installed to know what that does; but I don't believe it has typos in it ;)
So please provide more information about the exact security warnings once you've fixed - and validated (with the W3C Validator) - the structure of your HTML.
Edit: If the script is not intended to be there and has appeared outside of your desire:
Have a look in the HTML source where the script is present; and compare to your own ASPX pages to find out where the script is appearing. If it is being rendered by one of your controls you need to examine where the value is coming from. If it is a database, you need to focus your attention on what gets the information into the DB in the first place. If the script is injected and not into one of your controls then you should talk to your ISP I would think.

ASP.Net website makes browser load unwanted (non-referenced) plugins

I've found that some of my ASP.Net web apps prompt the browser to load plugins that I'm not explicitely using and certainly haven't deliberately referenced in the project settings.
Two that come to mind are for MS MediaPlayer and the "SVG Viewer for Netscape".
The only commonality I've determined so far is that the two sites/apps affected both use Master pages (nested in some cases).
We don't use SVG file types (just the normal mix of jpg/gif/png) and no video/audio (not yet anyway).
Can anyone provide a hint as to where the references for these might be creeping in? e.g. Is it a server-level include? Or a .Net runtime default when using master pages?
Does anyone else even experience this, or is it just me?
No urgency, I'd just like to remove it if possible.
Thanks.
Al
If you look at the page source in your browser, you should see what's in the page that requires a plugin. If you load external Javascript, you will have to look at that too. Do you have ads on the site that include 3rd party code?

Why in some dynamic website , their pages are in html format?

I've seen a lot of dynamic website through the internet that their pages are in html or htm format . I don't get it why is that ? And how they do that ?
Just look at this website : http://www.realmadrid.com/cs/Satellite/en/Home.htm
What you see in the URL can be set at will by the people running the web site. The technique is called URL rewriting.
How
On Apache, the most popular solution to that is the mod_rewrite module.
Seeing as you've tagged ASP.NET: As far as I know, ASP.NET has only limited rewriting support out of the box. This blog entry promises a complete URL rewriting solution in ASP 2.0
Why
As for the why, there is no compelling technical reason to do this.
It's just that htm and html are the recognized standard extensions for HTML content, and many (including myself) think they simply look nicer than .php, .php5, .asp, .aspx and so on.
Also, as Adam Pope points out in his answer, this makes it less obvious which server side technology/language is used.
The .html/.htm extension has the additional effect that if you save it to disk, it is usually automatically connected with your installed browser.
Maybe (a very big maybe) there are very stupid simple client programs around that recognize that they have to parse HTML by looking at the extension. But that would be a blatant violation of rules and was hopefully last seen in 1994. Anyway, I don't think this is the case any more.
There are a number of potential reasons, these may include:
They could be trying to hide the technology they built the site with
They could be serving a cached version of a page which was written out to HTML.
They could simply perceive it to look friendlier to the user
They might be using a server-side scripting language like PHP or ASP. You can configure what file extensions get parsed by the language by editing the web server configuration files.
For example in PHP the default extension is .php but you could configure the server to use .html, that would mean any files with the .html extension could contain PHP code they would get parsed before the page is sent to the clients web browser.
This is generally not recommend as it adds an overhead and .html pages that don't have any PHP would be parsed by the PHP engine anyway which is slower then serving pages direct to the browser.
The other way would be to use some form of URL rewriting. See URL Rewriting in ASP.NET
Another reason is SEO(Search engine optimization). Many search engines like html pages and many guys(I mean some SEO specialists) think the html can improve the rank of their content in search engine.
One possibility is just historical reasons. Pages that started static, now are generated dynamically, but sites don't want to break old customer's favorites.
They keep some pages as html because their content is not supposed to change frequently or not at all.
But you should also keep in mind the fact that some sites are dynamic but they change the page extention to html but original page remains same eg php or aspx, etc using htaccess or some frameworks like codeigniter etc.

Taking /Pages out of the SharePoint URL?

A customer is asking if there is anything we can do to remove "/Pages" from his Internet-facing MOSS publishing site. Some Googling reveals that some clever use of HTTPModules may be able to hide the presence of Pages, but I've yet to see an end-to-end working solution. Have any of you come up against this particular requirement, and if so, how did you resolve it?
The customer's main concern with /Pages is the SEO impact of it - if anyone has any way to mitigate those issues or can explain why having this extra level in your URL would not be a concern, that would be appreciated as well (and probably better, in the long run!)
Check out this posting. http://blog.mastykarz.nl/semantic-urls-in-moss-2007-imtech-sharepoint-semantic-urls-free-feature/
The main issue you'll have is that Microsoft won't provide support for a SharePoint instance that has "hidden" the pages library.
Yes, you can use a URL re-writer to exclude the /pages section of the path, and you will also need to perform a search and replace on the response stream to strip it out of all generated URLS - this will obviously have a performance hit on the server - but with careful use of caching, it might not be that noticable.
PSS will require you to remove the setup before they will investigate any issues with your site, so you (or your client) will need to weigh up the perceived benefits with the performance and support issues.
I believe we've done it for one of our clients in the past, but most are happy to stick with the /pages element - it really doesn't have that much effect.
I know ASP.NET 3.5 SP1 has the URL routing engine that ASP.NET MVC uses built in. If you wanted to run against that version of the .NET framework, you could use routes to eliminate the /Pages part of the URL. But I'm not positive about running MOSS on that version of .NET. That's the first place I'd check, though.
You can get a list of public facing websites using MOSS here. You can see they use the "page" libraries and you can check your favorite search engines against the content.
Hopefully this will be enough to demonstrate that the "Page" libraries aren't going to be too much of an issue and you can save them a bunch of cash.
You can change the name (and the url) of the /Pages library.

Resources