Are there any JavaScript vulnerabilites one should know about?

[SquaredPancake]

I've read on a topic about JavaScript that someone doesn't use JS on their site because it can open up potential security vulnerabilities, but that reply (or any subsequent reply) didn't really go into details of what those flaws could be.

I would give a serious word of caution to people who use JavaScript. I know from personal experience that it can be a very powerful- and dangerous- tool. Learned and tried it first hand in my software security class to hack into fake websites for demonstration purposes; if you're not careful, and don't take proper precautions to make your site secure, you could be open to some gnarly vulnerabilities.

I've used some JS on a site I built during an internship I took, but besides that, nah, I haven't used it. What I tried was painful, though. A friend of mine that I did senior capstone with swears by JS, but acknowledged that vanilla JS is tough to work with.

I myself use JavaScript minimally to provide neat and useful functionality while still making sure everything works when JS is disabled. I also write everything (except the snippets I copy from StackExchange and Co. ) myself and don't use any outside dependencies/libraries.

Is there any JavaScript security flaw one should know about for small, personal websites? And what are the worst things that can happen if someone exploits at least some of them?

[shevek]

I don't know if the original person meant something like what I am about to mention (fittingly I also wanted to make a topic about it just now, but I'll do it in the Help Section probably later, because it's a specific issue of mine), but cross-site scripting can be a problem with JavaScript (and libraries like jQuery) if any user input the user can give isn't "sanitized" (checked for special characters, converting special workarounds to their correct characters so the check can't be circumvented etc.).

To showcase it on a specific example, I am currently working on a website that has a terminal, so that means people visiting it can type words, press enter and it will do something. It can lead to a site, or show specific text.
If the user input is not sanitized, visitors could enter malicious code via the terminal and abuse my site (or when others offer this and also host sensitive info in their website, gain access to this).
I use a library that (by what I have researched so far) sanitizes the user inputs and certain parts are restricted to plain text, not HTML.
Though disclaimer, I am not an expert on this, I just coincidentally also wrangled with this last night  

[Necrosia]

It's comprehensible (and healthy!) that newbies are worrying about this sorta thing!   Most of the fear seems inherent from a lack of knowledge of how web site rendering and servers work, a lot of time people are just copy+pasting or using premade scripts with out truly understanding what they do and how they work. No worry, this is the right place to ask!

Here's a simplified explanation:

Server: A server is a computer or a program that provides services or resources to other computers or programs. It responds to requests from clients and delivers the requested data or performs specific tasks.

Client: A computer or a program that requests and consumes services or resources from a server. It is the user-facing component that interacts with the server to obtain the desired data or perform specific actions.

For example, when you access neocities.com on your computer, neocities.com acts as the server, and your computer (specifically, your web browser) acts as the client.

When you enter "neocities.com" in your web browser's address bar and press Enter, your web browser sends a client request to the neocities.com server, this request includes information such as the specific page or resource you're requesting.

Upon receiving the client's request, the neocities.com server processes the request. It retrieves the requested web page (such as the homepage or a specific URL) and prepares a response to be sent back to the client.

Once the client (your web browser) receives the server's response, it interprets the response and renders the web page accordingly. The client parses the HTML, CSS, and JavaScript files received from the server to display the web page's content, apply styles, and enable any interactive functionality.

If the web page includes frontend JavaScript code, the client (your web browser) executes that code locally on your computer. This JavaScript code can provide interactivity, dynamic content updates, and other client-side functionality. Throughout this process, data is exchanged between the client and server. The server (neocities.com) hosts the website and responds to client requests, while the client (your computer's web browser) sends requests and displays the received content.

Most programming languages are server-side only but javascript can be executed both on the backend(server) or the frontend(users's computer), when you load a web page that includes JavaScript, the browser takes on the role of executing that JavaScript code on the client-side. It's worth noting that different browsers may have variations in how they execute JavaScript and the performance of their JavaScript engines however, JavaScript is a standardized language, and most modern browsers support it.

Backend JavaScript: JavaScript code that runs on the server-side of a web application. It is executed on the server to handle server-side logic, database interactions, and generate responses for client requests.

Frontend JavaScript: JavaScript code that runs in a web browser. It enhances the user interface and enables interactivity on the client-side. It handles user interactions, manipulates the objects and communicates with the server to fetch data or update information.

Most of the danger lives on backend javaScript since users will probably be interacting with a database, sending their inputs and texts so if you don't manage the permissions and how you handle the user input properly it can let people access info and stuff they should not be able to! This is how some data leaks of user and passwords happen.

Adding little interactions and features to your site with frontend JavaScript alone is generally not dangerous. Frontend JavaScript is primarily executed on the client-side within the user's web browser, and it operates within the browser's security sandbox. This means it has limited access to the user's system and is isolated from sensitive resources.

However, while frontend JavaScript itself is not inherently dangerous, it's important to follow best practices and be mindful of potential security risks. Ensure that any user input (such as form submissions or user-generated content) is properly validated and sanitized on both the client-side and server-side. This helps prevent security vulnerabilities like cross-site scripting or code injection attacks and if you're using third-party JavaScript libraries or frameworks, keep them updated to the latest versions to address any security vulnerabilities that might have been discovered in previous versions.

[brisray]

@shevek has it. The biggest threat and the one you as an author can do most to stop it is to sanitize and validate everything your visitors are able to type into your website. It should be done whatever language you're using, JavaScript, SQL (usually used to access databases), Perl, Python, PHP, Java and so on.


Web servers are constantly being probed for vulnerabilites but unless you are sysop you don't have the privileges needed to protect them. A little while ago I wrote a page about server vulnerabilities and how I protect mine. Do you know what's wrong with that page? It's the fact that I wrote it at all, now everyone knows how I protect that computer which is itself a vulnerability.

Want to see what an attack against a server looks like? I've got loads of them in my live logs. Nearly all are by numpties and just create a bit of work for the server as they get squashed or redirected elsewhere. BTW, even making the log public is seen by some as a vulnerability.

[Salty]

@shevek has it. The biggest threat and the one you as an author can do most to stop it is to sanitize and validate everything your visitors are able to type into your website. It should be done whatever language you're using, JavaScript, SQL (usually used to access databases), Perl, Python, PHP, Java and so on.


Web servers are constantly being probed for vulnerabilites but unless you are sysop you don't have the privileges needed to protect them. A little while ago I wrote a page about server vulnerabilities and how I protect mine. Do you know what's wrong with that page? It's the fact that I wrote it at all, now everyone knows how I protect that computer which is itself a vulnerability.

Want to see what an attack against a server looks like? I've got loads of them in my live logs. Nearly all are by numpties and just create a bit of work for the server as they get squashed or redirected elsewhere. BTW, even making the log public is seen by some as a vulnerability.

Thanks for sharing this! I work more in the domain management sphere, and I don't have too much experience hardening web servers. Nice to check out what other sysadmins are doing re: apache.