Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-site scripting vulnerability #12221

Closed
11 tasks
TheRabbitX opened this issue May 28, 2021 · 8 comments
Closed
11 tasks

Cross-site scripting vulnerability #12221

TheRabbitX opened this issue May 28, 2021 · 8 comments
Labels
as designed Functionality is as designed security Type - Security wont/can't fix Result - Requested that can't be fixed/added or it is outside scope

Comments

@TheRabbitX
Copy link

PROBLEM DESCRIPTION

I've identified a Cross-site scripting vulnerability (XSS) in the web interface of Tasmota 6.5.0. Unfortunately, I can not check if the current release is also affected. It would be nice if someone could check this out and give me feedback.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

  • [ x] Read the Contributing Guide and Policy and the Code of Conduct
  • [ x] Searched the problem in issues
  • [x ] Searched the problem in discussions
  • Searched the problem in the docs
  • Searched the problem in the chat
  • Device used (e.g., Sonoff Basic): _____
  • Tasmota binary firmware version number used: _____
    • Pre-compiled
    • Self-compiled
  • Flashing tools used: _____
  • Provide the output of command: Backlog Template; Module; GPIO 255:
  Configuration output here:

  • If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
  Rules output here:

  • Provide the output of this command: Status 0:
  STATUS 0 output here:

  • Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:
  Console output here:

TO REPRODUCE

Navigate to "Configuration" - "Configure Other" and insert the following sting in the field "Friendly Name 1":
"/><script>alert(1)</script>

After that, a JavaScript alert box should appear if the version is vulnerable.

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here.

(Please, remember to close the issue when the problem has been addressed)

@sfromis
Copy link
Contributor

sfromis commented May 28, 2021

Testing this on 9.4.0.4, pasting "/><script>alert(1)</script> into friendly name and hitting save, I see nothing changed. In the console I'm seeing {"FriendlyName1":""} instead of the {"FriendlyName1":"asdfasdf"} when actually updating friendly name in the form. If I instead use /><script>alert(1)</script> (without the initial " from your suggestion) I do get the alert when reentering "Configure Other" after the restart.

However, to me this does not look like much of a "real" problem. If someone hostile gets access to screwing with my Tasmota devices, I'd likely have much bigger problems than this "detail". I'd certainly not be exposing them to the Internet, meaning that someone would have to breach my network in other ways to play around with Tasmota devices. And then they need no cross-site scriptring stuff, as they'd have much more straightforward ways of messing with me.

@Jason2866
Copy link
Collaborator

Jason2866 commented May 29, 2021

The ESP8266 is lacking any security feature by design. IMHO every ESP8266 device which is reachable from non authorized people or machines is a high security risk. A real hacker will find a way to break in a ESP8266 driven device. NEVER use Tasmota in a not secured wifi environment.
Keep this always in mind when using a ESP8266 device.
You cant make a ESP8266 secure!

@ascillato2 ascillato2 added the security Type - Security label Jun 3, 2021
@digiblur
Copy link
Contributor

digiblur commented Jun 7, 2021

Tuya figured out the security for now.

@Jason2866
Copy link
Collaborator

Jason2866 commented Jun 7, 2021

@digiblur No Open Source hacker is working on to break Tuya again on a ESP8266 device.
Do you really know if not someone has captured the devices?
No new designed TUYA device is with a ESP82xx. There are reasons for ;-)

@digiblur
Copy link
Contributor

digiblur commented Jun 7, 2021

Plenty of work has been done. No exploit found so far. The change of chipset isn't due to esp8266 security though.

@sfromis
Copy link
Contributor

sfromis commented Jun 7, 2021

For a long time, some Tuya vulnerabilities were found, and actively exploited, at least by Tuya-convert. Seems closed for newer iterations.

@Jason2866 Jason2866 added as designed Functionality is as designed wont/can't fix Result - Requested that can't be fixed/added or it is outside scope labels Aug 26, 2021
@Jason2866
Copy link
Collaborator

Wont and cant be fixed since it is a fight against windmills and the device does just not have the needed resources for. There is no chance to get the web interface hardened to call it secure. You showed one example. There are for sure many more. The webserver code in Arduino is a simple one. The only way to secure against such attacks, is to disable the webinterface. This is supported from Tasmota.

@arendst
Copy link
Owner

arendst commented Dec 18, 2023

Fixed in v13.3.0.1 f65ae06

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
as designed Functionality is as designed security Type - Security wont/can't fix Result - Requested that can't be fixed/added or it is outside scope
Projects
None yet
Development

No branches or pull requests

6 participants