Geeks Who Shower Games

import pygame,sys

def prompt(x,y,prompt_string,font,screen):
"""Create a prompt for a user to enter a string
Arguments:
x -- the x location of the input box to be rendered
y -- the y location of the input box to be rendered
prompt_string -- the string to be rendered in the input box
font -- the font to render the strings with
screen -- the main screen to render on
Returns:
return_string -- a string of what the user entered
"""
#the value to be returned
return_string=""
#calculate the size of the input box, and set it to the
width,height = font.size(prompt_string)
height=height*2+10
width=width+10
box = pygame.Rect((x-5, y-5), (width,height))
#draw the blue box around the input
screen.fill((0,0,255),box)
text = font.render(prompt_string,True,(255,255,255))
screen.blit(text,(x,y))
#calculate the white part of the input area
input_area = pygame.Rect((x, y+height/2-5), (width-10,height/2-5))
#loop until done(set if enter or escape is hit)
done=False
while not done:
#fill the input area with white
screen.fill((255,255,255),input_area)
#put what's currently inputted into the input area
input_text = font.render(return_string,True,(0,0,0))
screen.blit(input_text,(x,y+height/2-5))
pygame.display.flip()
#wait for an event
event=pygame.event.wait()
if event.type == pygame.KEYDOWN:
#if escape was hit assume the user doesn't want to enter anything, return nothing
if event.key == pygame.K_ESCAPE:
done=True
return_string=""
#if return was hit, assume the user is finished entering text and return what's been entered
elif event.key == pygame.K_RETURN:
done=True
#if backspace is hit, move the carat back one space and destroy the last letter
elif event.key == pygame.K_BACKSPACE:
#make sure there's something in the string first, don't want to kill what's not there
if len(return_string)>0:
return_string=return_string[0:len(return_string)-1]
else:
#add the typed letter to the string
return_string=return_string+event.unicode
return return_string

pygame.init()
size = width, height = 640, 480
screen = pygame.display.set_mode(size)
pygame.display.set_caption("Prompt test")
font=pygame.font.Font("Fontin-Regular.ttf",12)
frame=0
player_name=""
while 1:
for event in pygame.event.get():
if event.type == pygame.QUIT:
pygame.display.quit()
sys.exit()
if event.type == pygame.KEYDOWN:
if event.key==pygame.K_ESCAPE:
pygame.display.quit()
sys.exit()
if event.key==pygame.K_RETURN:
player_name=prompt(width/2-100,height/2-64,"Please enter your name:",font,screen)
screen = pygame.display.get_surface()
screen.fill((0,0,0))
text = font.render(player_name,True,(255,255,255))
screen.blit(text,(0,0))
pygame.display.flip()

Looking on the internet you can find a lot of tutorials on how to create web applications. However what most of these forget to tell you is that the majority of them are crap, either incorrect or insecure, and sometimes even both. Here is just a list of things that you should look out for no matter what you're doing in your web application, a crap tutorial can easily be spotted by a lack of including the following that are applicable to their web applications:

1. Improper memory management/Buffer overflows
When it normally occurs: When inputs are larger than the amount of memory allocated for the input
Why this is bad: A large enough buffer overflow may be able to make it to the executable portion of the program allowing arbitrary code execution
Ways to prevent it: The easiest way to prevent buffer overflows is by using string objects built into most languages rather than plain char arrays. Other ways to prevent this is to first find out how much memory is needed, then allocate it before assigning data to the variable. Another way is by trimming the input to fit the size of memory allocated for it.

2. SQL injection
When it normally happens: When invalidated user input makes it directly to the database
Why this is bad: It allows for the attacker to execute whatever SQL they want, giving them the ability to sabatoge or gain sensitive information from the database
How to prevent it: parameterize any queries that allow custom input

3. Cross-site scripting
When it normally happens: When user input is displayed and the html is not validated
Why this is bad: This allows attackers to execute whatever javascript they want and the browser thinks it's from your site, and with new technologies such as ajax they'll be able to retrieve the information across the network
How to prevent it: The easiest way to thwart this attack is to disallow html altogether, and use things like cgi.escape(python) or htmlspecialchars(php) to escape the html values from the input. If you're more adventerous you could create a regex to filter out scripts from the input.

4. Flooding
When it happens: When there is no restriction put on the attacker and they continously spam your program
Why this is bad: Waste of bandwidth and possibly disk space, could make a site look unprofessional, and in worst case scenarios cause DOS attacks. Also can lead to brute force cracking.
How to prevent it: Throttle the amount of bandwidth a user is allowed to use, also could invoke a timer every time input is recieved and disallow input until the timer is up.

5. Lack of CAPTCHA
When it happens: When the programmer is lazy and doesn't verify that who does the input is human
Why this is bad: It makes the web application an easy target for bots, which can range in severity from spam to DDOS attacks
How to prevent it: use a CAPTCHA when authenticating users or allowing guest entries

6. Invalidated includes
When it happens: When the includes are based on user input, and the attacker changes the input for their advantage
Why this is bad: First it can allow the attacker to trick the include system to disclose sensitive information. Another backlash is if the attacker gets the include file to include itself it could lead to an infinite loop and cause a DOS attack
How to prevent it: Whitelist the sites that are allowed to be included

These are just 6 very basic security considerations that should be taking into consideration when building a web application, not a comprehensive list. Publishing an application/tutorial without taking the above things into consideration is just being plain irresponsible