XSS vulnerability: <wslite> - php

A scurity report for my website show this vulnerability:
Relflected XSS:
Request: GET http://example.com/page.php?q=< wslite > HTTP/1.1
what is the meaning of this error, what is the meaning of <wslite>? and how can I solve this problem?
thanks

It means there is a GET vulnerability within the ?q section of your site. They can implant code there. Try visiting your site with ?q=<u>XSS</u>, and it should bring up the word XSS (underlined) somewhere within the page. These can be very dangerous. So ensure you sort it out. Update whatever CMS you are using, or use htmlentities() in PHP to ensure the user cannot insert HTML.

Related

How to prevent XSS vulnerability in wordpress site

When I directly write https://example.com/?trigger=*/</script><script>alert(1)</script> in url bar, it prompts the alert box.
How to fix this in a wordpress site?
I've tried some plugins like security headers, html purifier etc, but no success.
How to prevent these kind of vulnerabilities?
This plugin encode the following signs and then Remove some XSS signs from the URL:
Prevent XSS Vulnerability
You can Encodes or Block such type of Entities. You can also add Entities in Comma Separated Form which you do not want to be blocked/remove in the URL.
I personally use the free version of the Wordfence Security Plug-in. I tried your link on my site: https://www.majlovesreg.one/?trigger=*/</script><script>alert(1)</script> and no browser alert was created.
Looks like security plug-ins can do the job. :-)
There are many ways to prevent XSS on your website, you can block certain inputs such as special characters (<,>,/,) as well as only allow public users to input information when prompted to. Here is a great article to read to increase your knowledge, because sometimes you can't always find a plugin to fix your issue :)
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
p.s It also lists many more prevention methods.

PHP Security and XSS attacks - Getting Error Refused to execute a JavaScript script. Source code of script found within request

I'm going through my site and doing a security audit. I've simply accepted the fact that I need to sanitize ALL user input, but I've never really stopped and experimented with what's really going on. I'm starting to experiment now.
I have a typical contact form on a PHP page. It's _POSTing data. $_POST["first_name"]; etc.
I do this $firstName = htmlspecialchars($_POST["first_name"]); to sanitize and display a message like the one below.
echo $firstName . ', thank you for your interest. We'll be in touch soon!'
I started to play with this and if I enter something such as <script>alert('hello')</script> in the first name field, htmlspecialchars does it's job and coverts the tags.
When I remove htmlspecialchars the script doesn't get converted and it displays in the source as <script>alert('hello')</script> BUT, it does not execute.
My question is, why doesn't this execute? Isn't this basically what an XSS attack would do? Am I misunderstanding something?
When I tried this in Chrome I saw an error in the console:
Refused to execute a JavaScript script. Source code of script found within request.
So it's possible modern browsers do this check to prevent it. You should continue to sanitize your input regardless of course, but check your console and you will probably see this.

Examples of XSS that I can use to test my page input?

I have had issues with XSS. Specifically I had an individual inject JS alert showing that the my input had vulnerabilities. I have done research on XSS and found examples but for some reason I can't get them to work.
Can I get example(s) of XSS that I can throw into my input and when I output it back to the user see some sort of change like an alert to know it's vulnerable?
I'm using PHP and I am going to implement htmlspecialchars() but I first am trying to reproduce these vulnerabilities.
Thanks!
You can use this firefox addon:
XSS Me
XSS-Me is the Exploit-Me tool used to test for reflected Cross-Site
Scripting (XSS). It does NOT currently test for stored XSS.
The
tool works by submitting your HTML forms and substituting the form
value with strings that are representative of an XSS attack. If the
resulting HTML page sets a specific JavaScript value
(document.vulnerable=true) then the tool marks the page as vulnerable
to the given XSS string. The tool does not attempting to compromise
the security of the given system. It looks for possible entry points
for an attack against the system. There is no port scanning, packet
sniffing, password hacking or firewall attacks done by the
tool.
You can think of the work done by the tool as the same as the
QA testers for the site manually entering all of these strings into
the form fields.
For example:
<script>alert("XSS")</script>
"><b>Bold</b>
'><u>Underlined</u>
It is very good to use some of the automated tools, however you won't gain any insight or experience from those.
The point of XSS attack is to execute javascript in a browser window, which is not supplied by the site. So first you must have a look in what context the user supplied data is printed on the website; it might be within <script></script> code block, it might be within <style></style> block, it might be used as an attribute of an element <input type="text" value="USER DATA" /> or for instance in a <textarea>. Depending on that you will see what syntax you will use to escape the context (or use it); for instance if you are within <script> tags, it might be sufficient to close parethesis of a function and end the line with semicolon, so the final injection will look like ); alert(555);. If the data supplied is used as an html attribute, the injection might look like " onclick="alert(1)" which will cause js execution if you click on the element (this area is rich to play with especially with html5).
The point is, the context of the xss is as much important as any filtering/sanatizing functions that might be in place, and often there might be small nuances which the automated tool will not catch. As you can see above even without quotes and html tags, in a limited number of circumstance you might be able to bypass the filters and execute js.
There also needs to be considered the browser encoding, for instance you might be able to bypass filters if the target browser has utf7 encoding (and you encode your injection that way). Filter evasion is a whole another story, however the current PHP functions are pretty bulletproof, if used correctly.
Also here is a long enough list of XSS vectors
As a last thing, here is an actual example of a XSS string that was found on a site, and I guarantee you that not a single scanner would've found that (there were various filters and word blacklists, the page allowed to insert basic html formatting to customize your profile page):
<a href="Boom"><font color=a"onmouseover=alert(document.cookie);"> XSS-Try ME</span></font>
Ad-hoc testing is OK, however I also recommend trying a web application vulnerability scanning tool to ensure you haven't missed anything.
acunetix is pretty good and has a free trial of their application:
http://www.acunetix.com/websitesecurity/xss.htm
(Note I have no affiliation with this company, however I have used the product to test my own applications).

My page was attacked via xss, but on ftp all files are not changed?

yesterday i noticed that sometimes on my webpage shows up javascript errors.
when i went to source code, i found that one of .js files was totaly replaced with a ton of porn links.
i checked the ftp for this file, but there was just old javascript file without any changes.
yet i go back to check source code via browser and indeed there was again original .js
today i visited my webpage again and the problem repeated.
first visit showed me ton of porn pages
cached .js file was hacked
but after clearing browser cache js go back to oryginal
i checked all files on my ftp against my offilne version, but all files are without any change.
in last few years i was attacked by xss few times but in every case it was easy to diagnose and fix. but now i spend 12h and didnt find infection.
do you have any idea how to find it?
Most likely they've found an exploit inserting XSS data in your DB and / or CMS files, which then is displayed when you go to a specific page.
You seem to be using Quick CMS and it might contain some flaw somewhere, however if you've developed any custom functions yourself this might be where the problem is.
When you insert data into a DB always use the mysql escape function, and when you output the data from the DB on to the page use the php htmlentities() function, this will protect you from XSS attacks.
XSS attack does not need to change files at server side, it uses specially formatted query link which your code then renders to the webpage due to not checking inputs correctly.
You just need to escape or check your inputs. Search for "how to prevent xss".
Preventing Cross Site Scripting Attacks

PHP tags in URL

So I made a landing page for all these forms that the marketing department at my work makes. One of the fields they pass is a URL that I redirect to after I'm done processing - a thank you page.
Recently, I discovered a URL that looked like this:
http://www.oursite.com/folder/thank-you.php?thankyou=free-guide&adgroup=<?php echo nfpa-c ?>&reference=<?php echo ?>
Does this amount to anything but the form creator being dumb? My page is throwing huge errors about security and cross-site scripting, etc. What are the implications of this? Is there any legitimate reason to do this?
EDIT/UPDATE:
My landing page is in ASP.NET. The error it mentions is possible cross-site scripting.
<?php echo nfpa-c ?
I don't think it's the poster being dumb - this looks more like an outgoing form was not setup properly (e.g. PHP instructions used in a .html page that doesn't get parsed by the PHP interpreter.)
Check out the originating forms and look into their source code.
There is no legitimate reason to pass PHP code on the url like this. In fact it would be a Remote Code Execution Vulnerability, which is as bad as it gets its like like saying "Check Mate". I would make sure that that you don't have this code running, although its likely a bug because in php they would use eval("echo 'nfpa-c'");, you can't eval php tags like that, so its probably untested code.

Categories